Rundbrief des FA 5.2 Informationssystem-Architekturen

Transcription

Informationssystem
Architekturen
10. Jahrgang, Heft 2, Dezember 2003
Wirtschaftsinformatik
Rundbrief der GI-Fachgruppe WI-MobIS
Inhalt
Editorial .........................................................................3
Beiträge des Arbeitskreises WI-DWH: Modellierung
und Nutzung von Data-Warehouse-Systemen ..................5
Vorträge des 7. Workshops „Modellierung und Nutzung
von Data-Warehouse-Systemen“ auf der MobIS 2003
am 10. Oktober 2003 in Bamberg..................................................... 7
H.-J. Schwab, T. Schröer (SAP AG): Grundzüge des Datenschutzes
und ihre Umsetzung in Standard-Anwendungen .................................................9
R. Coloru (Loyalty Partner GmbH): Anwendung des Datenschutzes
im Data-Warehouse-System des Bonusprogrammes PAYBACK .......................27
T. Priebe, Prof. Dr. G. Pernul (Universität Regensburg): Sicherheit
in Data-Warehouse- und OLAP-Systemen........................................................45
Fachbeitrag ..................................................................................... 65
Dr. M. Böhnlein, Dr. A. Bauer (T-Systems Nova GmbH):
Todsünden des Data Warehousing ...................................................................67
Beiträge des Arbeitskreises WI-EPK: Geschäftsrozessmanagement mit Ereignisgesteuerten Prozessketten .....83
Bericht des Arbeitskreises WI-EPK................................................... 85
Fachbeitrag ..................................................................................... 87
J. Mendling, Dr. Markus Nüttgens: Konzeption eines XML-basierten
Austauschformates für Ereignisgesteuerte Prozessketten (EPK)..........................89
1
Beiträge des Arbeitskreises WI-KobAs: Komponentenorientierte betriebliche Anwendungssysteme ............. 105
Vorträge des 4. Workshops „Modellierung und Spezifikation
von Fachkomponenten“ auf der MobIS 2003
am 10. Oktober 2003 in Bamberg ................................................ 107
H. Wegener (Swiss Re), Dr. G. Auth (DaimlerChrysler TSS GmbH):
Spezifikation von Fachkomponenten mit der Swiss Re Data Language...........109
P. Fettke, Prof. Dr. P. Loos (Universität Mainz): Entwicklung
eines Metamodells für die „Vereinheitlichte Spezifikation
von Fachkomponenten“ .................................................................................121
J. Ackermann (Universität Augsburg): Spezifikation
von Fachkomponenten mit der UML 2.0 ........................................................131
A. Schmietendorf (Universität Magdeburg, T-Systems Nova),
R. Dumke (Universität Magdeburg), D. Reitz (Universität Magdeburg,
T-Systems Nova): Erfahrungen mit der Spezifikation von Web Services..........139
Einladung und Programm
zur 12. GI-Fachtagung MobIS 2004 ............................151
2
Editorial
Sehr geehrte Damen und Herren,
liebe Mitglieder der Fachgruppe WI-MobIS,
der eigentlich für Ende 2003 geplante Rundbrief ist in das neue Jahr gerutscht. Er fällt
dadurch aber umfangreicher und informativer als ursprünglich geplant aus und berichtet
ausführlich zu den Aktivitäten der Arbeitskreise der Fachgruppe WI-MobIS:
•
Die Beiträge des Arbeitskreises WI-DWH umfassen die Vorträge zum 7. Workshop im
Rahmen der MobIS 2003 sowie einen Fachbeitrag von M. Böhnlein und A. Bauer zu den
Todsünden des Data-Warehousing.
•
Aus dem Arbeitskreis WI-EPK liegen ein Bericht sowie ein Fachbeitrag von J. Mendling
und M. Nüttgens zur Konzeption eines XML-basierten Austauschformats für Ereignisgesteuererte Prozessketten (EPK) vor.
•
Der Arbeitskreis WI-KobAs steuert die Vorträge zum 4. Workshop im Rahmen der
MobIS 2003 bei.
Bei dieser Gelegenheit darf ich Sie bereits herzlich zur Teilnahme an der Multikonferenz
Wirtschaftsinformatik 2004 einladen, die von 9.−11. März 2004 in Essen stattfinden wird
(http://kom.wi-inf.uni-essen.de/mkwi04/default.htm). Die Multikonferenz umfasst 18 Teilkonferenzen, für den MobIS-Track zeichnet M. Rebstock verantwortlich.
Im Rahmen der Mitgliederversammlung in Essen steht die Neuwahl des Leitungsgremiums
der Fachgruppe gemäß Abschnitt 8 der Fachgruppenordnung an (siehe
http://www.seda.wiai.uni-bamberg.de/fg510/index.html). Eine gesonderte Einladung hierzu
mit einer vorläufigen Liste der zur Wahl stehenden Kandidatinnen und Kandidaten erhalten
Sie in Kürze. Die Liste kann bis zur Wahlversammlung sowie innerhalb der
Wahlversammlung durch weitere Vorschläge ergänzt werden.
Ermuntern möchte ich Sie auch zur Teilnahme an der Modellierung 2004 von 24.−26. März
2004 in Marburg sowie zur Einreichung von Beiträgen für die DW2004, die am 4. und 5.
November 2004 in Friedrichshafen stattfinden wird. Außerdem wirft die WI2005, die im
zweijährigen Turnus stattfindende große Wirtschaftsinformatik-Tagung, ihre Schatten voraus
(http://www.wi2005.de/). Die WI2005 wird von 23.−25. Februar 2005 in Bamberg stattfinden.
Ich wünsche Ihnen noch nachträglich ein erfolgreiches und gesundes Jahr 2004.
Mit herzlichen Grüßen
Ihr Elmar Sinz
3
4
Beiträge des Arbeitskreises WIWI-DWH:
Modellierung und Nutzung
von Data-Warehouse-Systemen
5
6
Vorträge des 7. Workshops
„Modellierung und Nutzung
von DataData-WarehouseWarehouse-Systemen“
auf der MobIS 2003
am 10. Oktober 2003 in Bamberg
7
8
Grundzüge des
Datenschutzes und
ihre Umsetzung in
StandardAnwendungen
Hermann-Josef Schwab
stellv. Datenschutzbeauftragter, SAP AG
Tom Schröer
Produkt Management Security, SAP AG
Agenda
Datenschutzgesetze weltweit
Grundsätze der EU-Richtlinie 95/46/EG
Umsetzung im Bundesdatenschutzgesetz
Gesetzliche Grundlagen in Deutschland
Beteiligte
Anforderungen an Anwendungen
Vorgehen Entwicklungsvorgaben
Grundsätzliche Anforderungen
Durchführung Datenschutz in
Deutschland (Datenschutzbeauftragter,
Strafen, Aufsichtsbehörde)
EU
USA
Zusammenfassung, Weitere Informationen
 SAP AG 2003, Grundzüge des Datenschutzes, H.-J. Schwab, T. Schröer 2
1
Quelle: http://www.privacyinternational.org/survey/
Weltweit unterschiedliche Vorschriften
Datenschutz wird weltweit sehr unterschiedlich gehandhabt
„Adäquates Datenschutzniveau“
von der EU anerkannt
EU-Richtlinie
streng reglementiert
Ungarn
F I
USA
EWR
EU-Richtlinie
D
Selbstreguliert,
einzelne Vorschriften
Save Harbor
Kanada
...
BDSG
COPPA
Argentinien
HIPPA
TKG
TDDSG
Mehrere hundert
weitere
Vorschriften!
Guernsey
FERPA
2
Agenda
Beteiligte
EU
USA
Grundsätze der EU Richtlinie 95/46/EG
I
Datenschutzgesetze der EU-Länder
EU-Datenschutzrichtlinie
3
zeitlich beschränkt
sachlich richtig
nicht exzessiv
Zweck entsprechend
eindeutiger Zweck
Rechtmäßigkeit
Datenschutz in der EU
II
ja
Zustimmung des Betroffenen?
nein
ja
Vertrag mit dem Betroffenen?
nein
ja
Gesetzliche Vorschrift?
nein
ja
Spezielle Regelungen?
!
nein
Verarbeitung zulässig
Nicht zulässig !
III
Besondere Arten von personenbezogenen Daten (nach Art.8):
n rassische und ethnische Herkunft
n politische Meinungen,religiöse oder philosophische Überzeugungen,
Gewerkschaftszugehörigkeit
n Daten über Gesundheit und Sexualleben
Diese „sensiblen“ Daten dürfen nur unter sehr restriktiven
Bedingungen verarbeitet werden:
n
n
n
n
n
Vorschriften des Arbeitsrechts bei angemessenen Garantien
Lebenswichtige Interessen der betroffenen Person oder Dritter
Mitglieder und Interessenten entsprechender Organisationen
Zustimmung der betroffenen Person
Die Daten wurden durch die betroffene Person selbst veröffentlicht
Ausnahmen:
n Gesundheitswesen, wenn die Verarbeitung durch Personen mit
Schweigepflicht erfolgt
4
Agenda
Beteiligte
EU
USA
Gesetzliche Grundlagen in Deutschland I
Bundesdatenschutzgesetz BDSG
Zweck des BDSG :
den Einzelnen davor zu schützen, dass er durch den Umgang mit seinen
personenbezogenen Daten in seinem Persönlichkeitsrecht
beeinträchtigt wird
(dies gilt unabhängig von Staatsangehörigkeit, Wohn- oder Aufenthaltsort des
Betroffenen)
Begriffsbestimmung:
Personenbezogene Daten sind Einzelangaben über persönliche oder
sachliche Verhältnisse einer bestimmten oder bestimmbaren
natürlichen Person (Betroffener)
Beispiele: Adresse, Telefonnummer, Kreditkartennummer, Gehalt,
Erkrankung
5
Gesetzliche Grundlagen in Deutschland II
Nicht durch das BDSG geschützt sind:
n anonymisierte Daten
n Daten von juristischen Personen (Firmen, Vereine, Körperschaften)
n Sachdaten
Aber:
n es gibt mehrere Hundert(!) Gesetze und Rechtsvorschriften außer
dem BDSG, die ebenfalls personenbezogene Daten schützen
(z.B. Sozialgesetzbuch, Telekommunikationsgesetz) und dem BDSG
teilweise vorgehen
n vertrauliche Daten eines Unternehmens, Betriebs- und
Geschäftsgeheimnisse werden z.B. durch Strafgesetzbuch,
Urheberrechtsgesetz, Gesetz gegen den unlauteren Wettbewerb,
Wertpapierhandelsgesetz etc. geschützt
Beteiligte an der Datenverarbeitung
Verantwortliche Stelle
(Unternehmensleitung, durch
Delegation auch einzelne Mitarbeiter)
•
•
•
Erheben
Verarbeiten
Nutzen
„Erheben“
StandardSoftware
Betroffene:
„Übermitteln“
Dritte
Kunden, Lieferanten,
Mitarbeiter, ...
Verarbeiten, Nutzen
6
Agenda
Beteiligte
EU
USA
Datenschutz im Programm?
Mindestanforderung:
n Der Anwender muss in der Lage sein, mit Standard-Software seinen
gesetzlichen Anforderungen zu genügen
n Zugangs- und Zugriffsschutz müssen programmtechnisch realisiert
sein
Besser:
Standard-Software
n ist datenschutzgerecht vorkonfiguriert
n unterstützt den Kunden, seine Geschäftsprozesse
datenschutzgerecht zu definieren
n Bietet Funktionen für:
u Protokollierung der Zustimmung / anderer Rechtsgrundlagen
u Auskunft, Sperren, Löschen
u Protokollierung der Übermittlung
u ...
7
Wie erfährt der Entwickler von
Datenschutzanforderungen?
Problem:
§
Gesetze,
Vorschriften,
Richtlinien
aus vielen
Staaten,
Regionen
Transfer der
Anforderungen
Entwickler
§
Entwicklungsvorgaben (1)
Unterstützung durch
zentrale Spezialisten
Eigenleistung der
Entwicklungsgruppen
Definition des Vorgehens
§
Gesetze
§
Frag‘ deine Kunden in den
allen/wichtigen Zielländern,
welche Datenschutzvorgaben
sie einhalten müssen
Überlege, welche
Anforderungen daraus
erwachsen
Kombiniere die Anforderungen
verschiedener Länder
Überlege, wie die
Anforderungen umsetzbar sind
8
Entwickler
§
Eigenleistung der
Entwicklungsgruppen
Zentrale Übersicht: es gibt in
folgenden Ländern folgende
Vorschriften
Überlege, welche
Anforderungen daraus
erwachsen
Gesetze
§
Entwickler
Überlege, wie die
§
Gesetze
Eigenleistung der
Entwicklungsgruppen
Vorschriften
Übersicht der Anforderungen
der verschiedenen Vorschriften
§
Überlege, wie die
9
Entwickler
§
Gesetze
§
Eigenleistung der
Entwicklungsgruppen
Vorschriften
Entwickler
Anforderungsprofil, dass die
Anforderungen der wichtigsten
Vorschriften/Staaten kombiniert
Überlege, wie die
§
Gesetze
§
Eigenleistung der
Entwicklungsgruppen
Vorschriften
Anforderungsprofil, dass die
Anforderungen der wichtigsten
Vorschriften/Staaten kombiniert
Umsetzungsvorschläge für die
Anforderungen (Algorithmen,
zentral nutzbare Funktionen,...)
10
Entwickler
Zustimmung und Datenvermeidung im Programm
Verbot mit Erlaubnisvorbehalt
Anwendung:
Ablage der Rechtsgrundlage der Verarbeitung
• Gesetz
• Vertrag
• Zustimmung des Betroffenen: Datum, Uhrzeit, Version,auch Widerruf vorsehen
Datenvermeidung und
Datensparsamkeit
Anwendung:
• Wenig Muss-Felder
• Zuschalt- bzw. abschaltbare Felder, Feldgruppen, ...
• Löschkonzept, - fristen, -programme
Datensparsamkeit (§3a) im Programm
Datenvermeidung durch
Verzicht auf Personenbezug
Pseudonymisierung
n Benutzung eines Pseudonyms, Personenbezug in Einzelfall
rekonstruierbar
n Z. B. Newsletter, Internetangebote
Anonymisierung
n wo nicht zwingend ein Personenbezug notwendig
n Testdaten
n Auswertungen (Data Warehouse, …)
n Personenbezug darf nicht rekonstruierbar sein
11
Rechte der Betroffenen im Programm
Verantwortliche Stelle:
Betroffene Person:
Pflichten
Rechte
Benachrichtigung
Auskunft
Berichtigung
Löschung
Sperrung
Anwendung:
• Kennzeichnung ‚Benachrichtigung erfolgt‘ mit Datum
• Zusammenstellung aller Daten zu einer Person in einem Report
• Korrektur (z.B. als Selfservice bei Internetanwendungen)
• Einbau echter Löschfunktionen (nicht nur Archivierung)
• Sperrkennzeichen, Grund der Sperrung
Die 8 Gebote des Datenschutzes: §9 BDSG + Anhang
8 Gebote
„Normale“
Sicherheitsanforderungen
Umsetzung (u.a.)
Zutrittskontrolle
Gebäudeschutz
Zugangskontrolle
Authentifizierung
Zugriffskontrolle
Berechtigungskonzept
Weitergabekontrolle
Dokumentation
Übermittlungswege
Eingabekontrolle
Protokollierung
Auftragskontrolle
Vertrag
Verfügbarkeitskontrolle
Hochverfügbarkeit,
Backup
Trennungskontrolle
Mandanten
12
Programm?
ü
ü
ü
ü
ü
Agenda
Beteiligte
EU
USA
Deutschland: Datenschutzbeauftragter
Auftrag (nach § 4 f u. g BDSG)
Der Beauftragte für den Datenschutz
§
§
§
§
§
wirkt auf die Einhaltung dieses Gesetzes und anderer Vorschriften über
den Datenschutz hin
überwacht die ordnungsgemäße Anwendung der Programme
macht die mit der Verarbeitung personenbezogener Daten beschäftigten
Personen mit den Vorschriften und Erfordernissen des Datenschutzes
vertraut
ist direkt der Unternehmensleitung unterstellt
er ist in Ausübung seiner Fachkunde auf dem Gebiet des Datenschutzes
weisungsfrei
Er hat keine Weisungsbefugnis!
13
BDSG: Aufsichtsbehörden im nichtöffentlichen
Bereich
n
Die Aufsichtsbehörde wird bei Verdachtsfällen, z.B. aufgrund einer
Beschwerde tätig. Sie kann aber auch anlass-unabhängige
Kontrollen durchführen.
n sie prüft die „verantwortlichen Stellen“, verhängt Bußgelder oder stellt
Strafanzeigen
n sie kann den Einsatz einzelner Verfahren untersagen, wenn schwerwiegende
Mängel vorhanden sind und trotz Anordnung der Behörde nicht beseitigt
werden
n sie kann die Abberufung des Beauftragten für den Datenschutz verlangen,
wenn dieser nicht die erforderliche Fachkunde und Zuverlässigkeit besitzt.
Die Aufsichtsbehörden werden von den Landesregierungen bestimmt
Baden-Württemberg: Innenministerium
Bayern: Regierung von Mittelfranken, Aufsichtsbehörde für den
Datenschutz in Ansbach
BDSG Straf- und Bußgeldvorschriften
§ 43 Bußgeldvorschriften
(3)Die Ordnungswidrigkeit kann im Falle des Absatzes 1 mit einer Geldbuße
bis zu fünfundzwanzigtausend Euro, in den Fällen des Absatzes 2 mit einer
Geldbuße bis zu zweihundertfünfzigtausend Euro geahndet werden.
§ 44 Strafvorschriften
(1) Wer eine in § 43 Abs. 2 bezeichnete vorsätzliche Handlung gegen Entgelt
oder in der Absicht, sich oder einen anderen zu bereichern oder einen anderen
zu schädigen, begeht, wird mit Freiheitsstrafe bis zu zwei Jahren oder mit
Geldstrafe bestraft.
(2) Die Tat wird nur auf Antrag verfolgt. Antragsberechtigt sind der Betroffene,
die verantwortliche Stelle, der Bundesbeauftragte für den Datenschutz und die
Aufsichtsbehörde.
14
Spezielle Datenschutzverfahren EU
n Übermittlung in Drittstaaten nur bei adäquatem Schutzniveau,
länderbezogene Feststellung durch die EU-Kommission,
Ausnahme: „Save Harbor“ Regelung in den USA
n Verfahrensverzeichnis:
Deutschland
EU-Staaten
Datenschutzbeauftragter
zentral bei den Aufsichtsbehörden mit Meldepflicht
n Deutschland:
Mitbestimmung durch Betriebsräte
n
kann Einführung von IT-Systemen in Unternehmen verhindern
n besonderes Augenmerk auf Leistungskontrolle/Überwachung von
Mitarbeitern
Beispiele Schutzvorschriften USA
In USA kein generelles
Datenschutzgesetz, aber einzelne
geregelte Inseln:
USA
n Family Education Rights and
Privacy Act (FERPA)
COPPA
n Health Insurance Portability and
Accountability Act (HIPAA)
HIPPA
VPPA
n Children's Online Privacy
Protection Act (COPPA)
n Fair Credit Reporting Act (FCRA)
FERPA
n Cable Communications Policy Act
n Telecommunication Act
FCRA
n Video Privacy Protection Act
(VPPA)
SB1386
n SB1386 (Kalifornien)
n …
15
Datenschutz in US: Selbstregulierung
n Problem bei Selbstregulierung:
Kann jederzeit geändert werden, kann schlecht kontrolliert
werden, keine Sanktionen
n Unterschiede im Verhältnis Betroffener <-> Unternehmen und
Betroffener <-> Staat
n „Privacy“ bezieht sich nur auf das „Privatleben“,
Arbeitnehmerdaten genießen keinen Schutz, „Dataprotection“
wird nicht im Sinne der EU-Richtlinie verstanden
n Staat hat Zugriff auf alle Daten (Patriots Act)
n z.B. auch auf weltweit alle personenbezogenen Daten von
internationalen Anbietern (z.B. alle Käufe/Verkäufe von Amazon,
Ebay seit 1995)
n Personenbezogene Daten von allen Fluggästen, die in USA
einreisen, mit Zustimmung der EU
Agenda
Beteiligte
EU
USA
16
Zusammenfassung
Folgende Punkte sollen bei der Entwicklung berücksichtigt
werden:
n technisch-organisatorische Maßnahmen nach §9 BDSG (Zugangs-,
Zugriffskontrolle)
n Protokollierung der Zustimmung
n Auskunft vorsehen (z.B. Reports)
n Sperren, Löschen, Widerruf in Geschäftsprozessen vorsehen
n Protokollierung der Übermittlung
n Löschfristen und Löschprogramme vorsehen
n Pseudonymisierung/Anonymisierung ermöglichen (wo
sinnvoll/möglich)
n Datenschutzgerechte Vorkonfiguration
n Wenige Muss-Felder, kritische Funktionen/Felder nur per
Administration aktivierbar
n Protokollierung von Schreibzugriffen, evtl. auch Lesezugriffen
n Dokumentation von Datenschutz-gerechtem Einsatz
Weiterführende Informationen
n
Datenschutz (Produkte)
Datenschutzleitfaden R/3
www.sap.de/revis
Hinweis: 30724 „Datenschutz und Sicherheit in SAP Systemen”
(nur bei Zugang zum SAP Service Marketplace)
DSAG-Arbeitsgruppe Datenschutz
www.dsag.de
SAP Security Product Management ([email protected])
n
Datenschutz im Internet (mit weiterführenden Links):
www.bfd.bund.de
www.datenschutz.de
Bundesbeauftragter für den
Datenschutz
Virtuelles Datenschutzbüro
www.europa.eu.int/comm/internal_market
17
Europäische Union
Thank You For Your Attention!
Contact persons:
Tom Schröer
PM Security
[email protected]
SAP Security Competence Team
E-Mail: [email protected]
H.-J. Schwab
stellv. Datenschutzbeauftragter
[email protected]
SAP AG Datenschutz
Copyright 2003 SAP AG. Alle Rechte vorbehalten
n
Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher
Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser
Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden.
n
Die von SAP AG oder deren Vertriebsfirmen angebotenen Softwareprodukte können Softwarekomponenten auch
anderer Softwarehersteller enthalten.
n
Microsoft®, WINDOWS ®, NT®, EXCEL®, Word ®, PowerPoint® und SQL Server® sind eingetragene Marken der
Microsoft Corporation.
n
IBM ®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390 ®, AS/400®, OS/390®,
OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere ®, Netfinity®, Tivoli ®, Informix
und Informix® Dynamic ServerT M sind Marken der IBM Corporation in den USA und/oder anderen Ländern.
n
ORACLE® ist eine eingetragene Marke der ORACLE Corporation.
n
UNIX®, X/Open ®, OSF/1® und Motif® sind eingetragene Marken der Open Group.
n
Citrix®, das Citrix-Logo, ICA ®, Program Neighborhood ®, MetaFrame®, WinFrame®, VideoFrame ®, MultiWin ® und
andere hier erwähnte Namen von Citrix-Produkten sind Marken von Citrix Systems, Inc.
n
HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken des W3C®, World Wide Web Consortium,
Massachusetts Institute of Technology.
n
JAVA® ist eine eingetragene Marke der Sun Microsystems, Inc.
n
JAVASCRIPT ® ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der Lizenz der von
Netscape entwickelten und implementierten Technologie.
n
MarketSet und Enterprise Buyer sind gemeinsame Marken von SAP AG und Commerce One.
n
SAP, R/3, mySAP, mySAP.com, xApps, xApp und weitere im Text erwähnte SAP-Produkte und –Dienstleistungen
sowie die entsprechenden Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und anderen
Ländern weltweit. Alle anderen Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen.
18
MobIS 2003
Anwendung des Datenschutzes im Data Warehouse
System des Bonusprogrammes PAYBACK
Bamberg, 10. Oktober 2003
MobIS 2003 - Workshop Datenschutz und Datensicherheit von Data-Warehouse-Systemen
1
Die Inhalte des Workshops
A
Kurzvorstellung PAYBACK
B
Rechtliche Rahmenbedingungen f r PAYBACK
C
Anwendung des Datenschutzrechts bei PAYBACK
2
A
Kurzvorstellung PAYBACK
3
PAYBACK ist das Nr. 1 Bonusprogramm in Deutschland
23 Mio. eingesetzte
Karten
Mit 66% bekannter
als jedes andere
Programm
(gest tzte Markenbekanntheit)
Mehr als 200 Mio. EUR
einl sef higes,
gesammeltes
Pr mienvolumen
Durchschnittlicher
Karteneinsatz
4 x pro Monat
Die 3. wichtigste Karte
im Geldbeutel
(nach Krankenkassenkarte
und EC Karte)
Erfolgreichstes
VISA Programm
in Deutschland in 2002
(130.000 ausgegebene Karten)
4
PAYBACK verf gt ber eine starke Online Pr senz
Unter den TOP 10
E-Commerce Websites
www.payback.de
(Quelle: Nielsen Netratings)
> 2 Mio. unique Visitors
pro Monat
Integrierter Online
Shopping Guide
5
100 Mio. qualifizierte Kundenkontakte ber verschieden Kan le erm glichen
einzigartige Direktmarketing-Effekte
Kommunikationskanal
(Auflagen: 2003)
Mailing
44 Mio. Mailings
SMS
8 Mio. SMS
Email
13 Mio. PAYBACK Bestandskunden
mit Adresse u. qualifizierenden Daten
34 Mio. Newsletter
Internet
24 Mio. Visits
POS
150 Terminals
6
Leistungsstarke Data Mining und Kampagnen Management
Funktionalit ten lassen Datensch tzer aufmerksam werden
Response
Analyse &
Report
DATABASE
KundenDatenbank
5
Response
Tracking
4
Customer
Service Center
1
Kampagnenplanung
6
Kundensegmentierung,
Scoring,
Selektion 2
Data
Mining/
Mining/
KampagnenKampagnenMgmt.
Mgmt.
KampagnenDesign
Durchf hrung
3
Outbound
eMail
Outbound
SMS
Outbound
Mail
ProgrammKunde
Homepage
www.payback.de
Response Monitoring
B
7
Rechtliche Rahmenbedingungen f r PAYBACK
8
Unternehmen m ssen beim Ringen um die Gunst des Kunden
vielf ltige Gesetze und Regelungen beachten
Wettbewerbsrecht
Datenschutzrecht
Verbraucherschutzgesetze
Preisangabe/
-bindung
Kartellrecht
9
Unternehmen m ssen beim Ringen um die Gunst des Kunden
vielf ltige Gesetze und Regelungen beachten
Wettbewerbsrecht
Datenschutzrecht
Preisangabe/bindung
Verbraucherschutzgesetze
Kartellrecht
10
C
Anwendung des Datenschutzrechts bei PAYBACK
1 - Ziel des Datenschutzes
2 - Rechtliche Vorgaben
3 - Umsetzung bei PAYBACK
C
11
12
Datenschutzrecht
1 - Ziel des Datenschutzes
Ziel des Datenschutzes
•
Die Bedeutung von Informationstechnologien w chst stetig; die Menge und
Qualit t der Datengewinnung- und auswertung nimmt zu.
•
Jede Verarbeitung personenbezogener Daten tangiert Pers nlichkeitsrechte
des Betroffenen
•
Gefahr der Kollision mit dem verfassungsrechtlich verb rgten Recht auf
informationelle Selbstbestimmung (Volksz hlungsurteil)
Grundsatz: „Verbot mit Erlaubnisvorbehalt“
(§ 4 Bundesdatenschutzgesetz, BDSG)
C
13
14
Datenschutzrecht
2 - Rechtliche Vorgaben
Das Bundesdatenschutzgesetz ist die zentrale Norm
Anwendungsbereich des BDSG bei privaten Stellen (nat. und jur. Personen)
personenbezogene Daten
= Einzelangaben ber pers nliche und sachliche Verh ltnisse einer
bestimmten oder bestimmbaren
nat rlichen Person (z.B. Kundendaten, Mitarbeiterdaten, etc.)
ja
nicht ausschlie lich f r pers nliche & famili re Zwecke
ja
Automatisierte Datenverarbeitung
ja
BDSG
15
Adressaten datenschutzrechtlicher Verpflichtungen sind die Mitarbeiter
und kontrollierende Beauftragte
Datenschutzbeauftragte, § 4f
Mitarbeiter, § 5 BDSG
„Den mit der Datenverarbeitung
besch ftigten Personen ist untersagt,
personenbefugte Daten unbefugt zu
erheben, zu verarbeiten oder zu nutzen
(Datengeheimnis). Diese Personen sind,
soweit sie bei nicht ffentlichen Stellen
besch ftigt werden, bei der Aufnahme
ihrer T tigkeit auf das Datengeheimnis
zu verpflichten. Das Datengeheimnis
besteht auch nach Beendigung ihrer
T tigkeit fort“
Verpflichtung aller Loyalty PartnerMitarbeiter bei Besch ftigungsbeginn
• berwachung der Anwendung der
Datenverarbeitung (auch
„Vorabkontrolle“)
• Datenschutzschulung
Regierung
von Mittelfranken
Betrieblicher Datenschutzbeauftragter bei Loyalty Partner ist der
Konzerndatenschutzbeauftragte der
Deutschen Lufthansa AG
Anchormen bei Loyalty Partner sind
zwei Mitarbeiter aus der Rechts- und
Operationsabteilung
16
Zul ssigkeit der Erhebung, Verarbeitung und Nutzung werden direkt
und indirekt geregelt
Einwilligung, § 4a BDSG
„Die Einwilligung ist nur wirksam, wenn Sie auf
der freien Entscheidung des Betroffenen beruht.
Es ist auf den vorgesehenen Zweck der
Erhebung, Verarbeitung oder Nutzung (...)
hinzuweisen.
Die Einwilligung bedarf der Schriftform, soweit
nicht wegen besonderer Umst nde eine andere
Form angemessen ist. Soll die Einwilligung
zusammen mit anderen Erkl rungen schriftlich
erteilt werden, ist sie besonders hervorzuheben.
Eigene Zwecke, § 28 BDSG
„Das Erheben, Speichern, Ver ndern oder
bermitteln personenbezogener Daten oder ihre
Nutzung als Mittel f r die Erf llung eigener
Gesch ftszwecke ist zul ssig:
1. Wenn es der Zweckbestimmung eines
Vertragsverh ltnisses oder vertrags hnlichen
Vertrauensverh ltnisses mit dem Betroffenen dient
2. Soweit es zur Wahrung berechtigter
Interessen der verantwortlichen Stelle erforderlich
ist und kein Grund zu der Annahme besteht, dass
das schutzw rdige Interesse des Betroffenen an
dem Ausschluss der Verarbeitung oder Nutzung
berwiegt,
(...)
Bei der Erhebung personenbezogener Daten sind
die Zwecke f r die die Daten verarbeitet oder
genutzt werden sollen, konkret festzulegen.
C
17
Datenschutzrecht
3 - Umsetzung bei PAYBACK
18
Der Umgang mit personenbezogenen Daten betrifft jeden Schritt im
Data Warehouse Prozess
Erhebung
Verarbeitung
- speichern
- ver ndern
- bermitteln
- sperren
- l schen
Nutzung
Reporting
Stammdaten
Datenanalysen
Transaktionsdaten
Data Warehouse
Call Center
Bewegungsdaten
Lettershop
19
PAYBACK st tzt die Datenverarbeitung und -nutzung auf mehrere
rechtliche Grundlagen: das Gesetz...
§ 28 I S. Nr. 1 BDSG
„im Rahmen der Zweckbestimmung eines Vertragsverh ltnisses“
Ø Verarbeitung und Nutzung der Daten der PAYBACK Kunden zur
technischen Abwicklung des Programms (Rabattgew hrung)
§ 28 I S. 1 Nr. 2 BDSG
„zur Wahrung berechtigter Interessen“
Ø Verarbeitung und Nutzung der Daten der PAYBACK Kunden zu
Werbe- und Marktforschungszwecken
20
...sowie auch auf die Einwilligung des Kunden
21
Die PAYBACK Datenschutzhinweise konkretisieren die Zwecke der
Datenverarbeitung und- nutzung ...
Wenn Sie am PAYBACK Programm teilnehmen, wird Ihr voller Name, Ihr
Geburtsdatum und Ihre vollst ndige Anschrift ben tigt (Basisdaten). Die
ber das Anmeldeformular insgesamt mitgeteilten Daten werden durch die
Firma Loyalty Partner GmbH, Postfach 232103, 85330 M nchenFlughafen zur Abwicklung des PAYBACK Programms erhoben,
gespeichert und genutzt. Die Basisdaten, freiwilligen Angaben und ggf.
deren nderungen, bermittelt Loyalty Partner an das
Partnerunternehmen, ber welches Sie Ihre PAYBACK Karte erhalten
haben. Sollten Sie Ihre PAYBACK Karte direkt von PAYBACK erhalten
haben, erfolgt eine solche bermittlung nicht. Eine bermittlung an die
brigen Partnerunternehmen oder au erhalb des Programms stehende
Dritte ist in jedem Fall ausgeschlossen.
Setzen Sie Ihre PAYBACK Karte bei einem Partnerunternehmen ein, so
meldet dieses die Rabattdaten (Waren/Dienstleistungen, Preis,
Rabattbetrag, Ort und Datum des Vorgangs) an Loyalty Partner zur
Gutschrift, Abrechnung gegen ber den Partnerunternehmen, Verwaltung
und Auszahlung der Rabatte. Eine bermittlung von Rabattdaten an die
brigen Partnerunternehmen sowie an au erhalb des Programms
stehende Dritte ist ausgeschlossen.
Haben Sie zur Auszahlung der Rabatte Ihre Bankverbindung angegeben,
so wird diese nur durch Loyalty Partner erhoben, gespeichert und zur
Auszahlung genutzt.
Auf Anforderung teilt Ihnen Loyalty Partner mit, ob und welche
pers nlichen Daten ber Sie gespeichert sind.
22
Die PAYBACK Datenschutzhinweise konkretisieren die Zwecke der
Datenverarbeitung und- nutzung ...
Wenn Sie am PAYBACK Programm teilnehmen, wird Ihr voller Name, Ihr
Geburtsdatum und Ihre vollst ndige Anschrift ben tigt (Basisdaten). Die
ber das Anmeldeformular insgesamt mitgeteilten Daten werden durch die
Firma Loyalty Partner GmbH, Postfach 232103, 85330 M nchenFlughafen zur Abwicklung des PAYBACK Programms erhoben,
gespeichert und genutzt. Die Basisdaten, freiwilligen Angaben und ggf.
deren nderungen, bermittelt Loyalty Partner an das
Partnerunternehmen, ber welches Sie Ihre PAYBACK Karte erhalten
haben. Sollten Sie Ihre PAYBACK Karte direkt von PAYBACK erhalten
haben, erfolgt eine solche bermittlung nicht. Eine bermittlung an die
brigen Partnerunternehmen oder au erhalb des Programms stehende
Dritte ist in jedem Fall ausgeschlossen.
Setzen Sie Ihre PAYBACK Karte bei einem Partnerunternehmen ein, so
meldet dieses die Rabattdaten (Waren/Dienstleistungen, Preis,
Rabattbetrag, Ort und Datum des Vorgangs) an Loyalty Partner zur
Gutschrift, Abrechnung gegen ber den Partnerunternehmen, Verwaltung
und Auszahlung der Rabatte. Eine bermittlung von Rabattdaten an die
brigen Partnerunternehmen sowie an au erhalb des Programms
stehende Dritte ist ausgeschlossen.
Haben Sie zur Auszahlung der Rabatte Ihre Bankverbindung angegeben,
so wird diese nur durch Loyalty Partner erhoben, gespeichert und zur
Auszahlung genutzt.
Auf Anforderung teilt Ihnen Loyalty Partner mit, ob und welche
pers nlichen Daten ber Sie gespeichert sind.
23
... und schaffen Transparenz !
Nur wenn Sie bei der Anmeldung Ihre diesbez gliche Einwilligung erteilt
haben, nutzt Loyalty Partner die Basisdaten, freiwilligen Angaben und
Rabattdaten zu Zwecken der Marktforschung sowie zur individuellen
Erstellung und Versendung ausgew hlter Informationen per Post, des
PAYBACK E-Mail Newsletters sowie von SMS (Werbung). Daneben kann
das Partnerunternehmen, von dem Sie Ihre PAYBACK Karte erhalten
haben, Ihre Basis- und dort anfallenden Rabattdaten sowie Ihre freiwilligen
Angaben zu eigenen Zwecken der Marktforschung und der Versendung
von Informationen per Post nutzen.
Ihre diesbez gliche Einwilligung k nnen Sie jederzeit gegen ber dem
PAYBACK Service Center, Postfach 232102, 85330 M nchen-Flughafen
oder der Loyalty Partner GmbH, Postfach 232103, 85330 M nchenFlughafen, widerrufen. Das ggf. betroffene Partnerunternehmen wird von
Loyalty Partner ber Ihren Widerruf informiert. Haben Sie Ihre Einwilligung
nicht erkl rt oder widerrufen Sie diese, findet eine Datennutzung nach
vorstehendem Absatz nicht statt. Selbstverst ndlich k nnen Sie aber am
PAYBACK Programm teilnehmen bzw. weiterhin teilnehmen. Sie erhalten
dann lediglich die zur Abwicklung des Programms notwendigen
Informationen (z.B. Punktestandsmitteilungen).
Zur Versendung von Informationen per Post, des PAYBACK E-Mail
Newsletters sowie von SMS werden die notwendigen Basisdaten fallweise
durch
beauftragte
Dienstleistungsunternehmen
verarbeitet
(Auftragsdatenverarbeiter). Unmittelbar nach Durchf hrung der Aktion
werden Ihre Daten dort gel scht. Jede M glichkeit einer Identifizierung
Ihrer Person durch Partnerunternehmen oder Dritte ist ausgeschlossen.
24
... und schaffen Transparenz !
Nur wenn Sie bei der Anmeldung Ihre diesbez gliche Einwilligung erteilt
haben, nutzt Loyalty Partner die Basisdaten, freiwilligen Angaben und
Rabattdaten zu Zwecken der Marktforschung sowie zur individuellen
Erstellung und Versendung ausgew hlter Informationen per Post, des
PAYBACK E-Mail Newsletters sowie von SMS (Werbung). Daneben kann
das Partnerunternehmen, von dem Sie Ihre PAYBACK Karte erhalten
haben, Ihre Basis- und dort anfallenden Rabattdaten sowie Ihre freiwilligen
Angaben zu eigenen Zwecken der Marktforschung und der Versendung
von Informationen per Post nutzen.
Ihre diesbez gliche Einwilligung k nnen Sie jederzeit gegen ber dem
PAYBACK Service Center, Postfach 232102, 85330 M nchen-Flughafen
oder der Loyalty Partner GmbH, Postfach 232103, 85330 M nchenFlughafen, widerrufen. Das ggf. betroffene Partnerunternehmen wird von
Loyalty Partner ber Ihren Widerruf informiert. Haben Sie Ihre Einwilligung
nicht erkl rt oder widerrufen Sie diese, findet eine Datennutzung nach
vorstehendem Absatz nicht statt. Selbstverst ndlich k nnen Sie aber am
PAYBACK Programm teilnehmen bzw. weiterhin teilnehmen. Sie erhalten
dann lediglich die zur Abwicklung des Programms notwendigen
Informationen (z.B. Punktestandsmitteilungen).
Zur Versendung von Informationen per Post, des PAYBACK E-Mail
Newsletters sowie von SMS werden die notwendigen Basisdaten fallweise
durch
beauftragte
Dienstleistungsunternehmen
verarbeitet
(Auftragsdatenverarbeiter). Unmittelbar nach Durchf hrung der Aktion
werden Ihre Daten dort gel scht. Jede M glichkeit einer Identifizierung
Ihrer Person durch Partnerunternehmen oder Dritte ist ausgeschlossen.
25
Warum st tzt sich PAYBACK sowohl auf das Gesetz als auch auf eine
Einwilligung ?
• Deckt der § 28 I S.1 Nr.2 das gesamte Spektrum
der Datenverarbeitung ab, z.B. die Selektion von Daten
nach bestimmten Kriterien?
• Wie kann eine Einzelfallabw gung von Interessen
im Massengesch ft funktionieren?
flie ende Grenzen f rdern den Ruf nach einer Reform
26
Auch mit einer Einwilligung verbleiben offene Punkte
• Einwilligung nur als klassisches "opt in"?
• Wie konkret muss die Zweckangabe sein?
• Ist nun jegliches Spektrum von Datenverarbeitung
abgedeckt?
• Ist die Einwilligung nach BDSG auch konform mit
dem Recht der AGB?
100% Rechtssicherheit ist nicht zu erreichen
27
Jedoch: die Unsicherheit ist kein reines PAYBACK Problem !
• betroffen sind alle Branchen, die mit Kundendaten
arbeiten und CRM betreiben
• Direktmarketingbranche
• Banken und Versicherungen
• Handelskonzerne und Versandh user
• und und und ...
28
Verst
e gegen das BDSG k nnen vielf ltige Sanktionen ausl sen
M gliche Folgen:
Unterrichtung der
Gewerbeaufsicht,
§38 I S. 4 BDSG
Entzug der
Gewerbeerlaubnis droht
(bei schwerwiegenden
Verst en)
Zwangsgeld,
§ 38 V S. 1,2
Bu geld,
§ 43 BDSG
Zur Durchsetzung von
angeordn. Ma nahmen
zur M ngelbeseitigung
beim technisch-organisatorischen Datenschutz
bei:
- rechtswidriger
bermittlung / Nutzung
von Daten
-falscher Belehrung
Strafe,
§ 44 BDSG
Haft oder Freiheitsstrafe,
wenn ein Versto mit
Vorsatz und in der
Absicht, sich zu bereichern oder jmd.
zu sch digen
Den Aufsichtsbeh rden stehen scharfe Sanktionsmittel zur Verf gung
29
Weitere Ma nahmen unterst tzen den sorgf ltigen Umgang mit den
Kundendaten
Mitarbeiter
Partner
Nutzung der Kundendaten
Dienstleister
BDSG
30
Nicht alle PAYBACK Mitarbeiter k nnen alles sehen
Mitarbeitergruppe
Marketing, Partneraccount
Welche Daten sind sichtbar?
• Keine Individualdaten sichtbar
•
Finance
berweisungsdaten
• Nur anonymisierte Testdaten
IT Development
• Kontaktdaten incl. Historie
Call Center
Database Marketing
Online Marketing
Business Intelligence
• Pseudonymisierte Daten aus Data Warehouse
• Keine Individualdaten sichtbar
• Alles
31
Die Datenfl sse zwischen Dienstleister, Partnern und Loyalty Partner
unterliegen definierten Regeln
Payment/
Zahlungsfunktion
PunchOffice
+
weitere
Partner
Transaktionen
Formularverarbeitung
Abwicklung von
Zahlungstransaktionen
Web
Call Center / IVR
LMS
Mailings,
Newsletter, SMS
Kartenproduktion
Data Warehouse
Letter Shop,
eMailVersender,
SMS-Provider
32
Alle Datenstr me zwischen den beteiligten Unternehmen laufen ber
Loyalty Partner oder werden durch Loyalty Partner koordiniert
Partner
Lettershop
• Eigenakquirierte Daten
• Personalisierungsinformationen
• Datenaktualisierungen
• Adressinformationen
• Content f r Partner Mailing
• Transaktionsdaten
Kartenproduzent
E-Mail / SMS Versender
• Kartennummer
• Auswertung von Reportings bzgl.
– Mafo
– Call Center etc.
33
Zusammenfassend die Ma nahmen zum Datenschutz, die bei Loyalty
Partner im Betrieb des Kundenbindungsprogrammes PAYBACK gelebt
werden
• Verpflichtung und Schulung der Mitarbeiter zum Datenschutz
• Review und Kontrolle der Aktivit ten innerhalb des PAYBACK Programms durch den
Datenschutzbeauftragten des Lufthansa Konzerns
• Konsequente Offenlegung der Datenverarbeitungsabsicht gegen ber dem Kunden
• Ausschlie liche Verwendung von Opt-In zur Erlangung der Zustimmung zur Datennutzung
• M glichkeit der Dateneinsichtnahme durch den Kunden
• Granulares Berechtigungskonzept in der IT Infrastruktur zur Datenverwendung
• Pseudonymisierung der Daten im Data Warehouse
• Nicht alle Daten sind zielf hrend (WWW)
Grunds tzlich:
Das Vertrauen des Kunden ist durch nichts zu ersetzen!
34
F r weitere Fragen stehen ich gerne zur Verf gung
Ansprechpartner bei Loyalty Partner
Raimondo Coloru
Business Intelligence
Tel.:
Mobil:
Fax:
E-Mail:
+49 (0)89 – 99 741-626
+49 (0)173 – 5 720 719
+49 (0)89 – 99 741-627
[email protected]
Copyright © 2003 by Loyalty Partner GmbH
No part of this publication may be reproduced by any means (photocopying, microfilm, recording or otherwise) or stored, processed,
duplicated or distributed by electronic means without the prior written permission of Loyalty Partner GmbH
35
SICHERHEIT IN DATA-WAREHOUSE- UND
OLAP-SYSTEMEN
Torsten Priebe, Günther Pernul
Lehrstuhl für Wirtschaftsinformatik I – Informationssysteme
Universität Regensburg, D-93040 Regensburg
{torsten.priebe, guenther.pernul}@wiwi.uni-regensburg.de
http://www-ifs.uni-regensburg.de
Data Warehouses erzeugen naturgemäß einen Sicherheitskonflikt. Grundidee des Data
Warehousing ist die Vereinfachung des Datenzugriffs zur Entscheidungsunterstützung.
Allerdings werden in Data Warehouses hochsensible Daten gespeichert, die zur strategischen
Entscheidungsfindung verwendet werden und somit vor unberechtigtem Zugriff geschützt
werden müssen. Dieser Beitrag stellt eine umfassenden Analyse der Sicherheitsproblematik in
Data-Warehouse-Systemen dar. Es werden zwei Forschungsansätze identifiziert: der BottomUp-Ansatz zur Ableitung von Zugriffsrechten für das Data Warehouse von den Datenquellen
und der Top-Down-Ansatz zum expliziten Entwurf von OLAP-Zugriffsrechten. Zu enge
Sicherheitsrestriktionen können Analysen behindern oder sogar Abfrageergebnisse
verfälschen, und damit zu falschen Entscheidungen führen, weshalb beim Entwurf von OLAPSicherheit äußerste Sorgfalt angesagt ist. Hierzu wird eine im Rahmen des EUForschungsprojektes GOAL entwickelte Methodik vorgestellt.
1. Einleitung
Eines der Hauptprobleme analytischer Informationssystemen ist die Heterogenität der
operativen Systeme. Vor diesem Hintergrund ist das Data-Warehouse-Konzept als
Integrationsbasis entstanden. Data-Warehouse-Technologien wurden in vielen Branchen
erfolgreich eingeführt: z.B. Produktion (Versand und Kundenbetreuung), Retail
(Inventarmanagement), Finanzen (Risikoanalyse), Transport (Flottenmanagement),
Telekommunikation, Energie (Verbrauchsanalyse) und Gesundheitswesen [1]. Neben diesen
klassischen Anwendungen werden Data Warehouses inzwischen vermehrt auch zum
Kundenbeziehungsmanagement, speziell im e-Business, eingesetzt (vgl. z.B. [12]).
Dieser Beitrag beschäftigt sich mit Sicherheitsstrategien für Data-Warehouse-Systeme.
Sicherheit im Data Warehouse ist eine komplexe Problematik. Kimball [9] schreibt: „Ein
Data Warehouse erzeugt naturgemäß einen Sicherheitskonflikt.“ Grundidee des Data
45
Warehousing ist die Vereinfachung des Datenzugriffs zur Entscheidungsunterstützung.
Demgegenüber steht die Tatsache, dass in Data Warehouses hochsensible Daten (z.B.
Finanzdaten) gespeichert sind, die zur strategischen Entscheidungsfindung verwendet werden
und somit vor unberechtigtem Zugriff geschützt werden müssen. Zu enge Sicherheitsrestriktionen können Analysen jedoch behindern oder sogar Abfrageergebnisse
verfälschen, und damit zu faschen Entscheidungen führen.
Zur weiteren Berarbeitung der Thematik sollen zunächst einige Begrifflichkeiten geklärt
werden. Inmon [6] definiert ein Data Warehouse als „themenorientierte, integrierte, nichtflüchtige, zeitvariante Datensammlung zur Management-Unterstützung“. Data Warehousing
ist also als Technik zur Integration und Historisierung von Daten zu Analysezwecken zu
sehen. Kernidee ist die physische Trennung der operativen (transaktionsorientierten) und
dispositiven (analyseorientierten) Datenhaltung. Aufgrund der Historisierung können dabei
immense Datenmengen, bis in den Terabyte-Bereich, entstehen. Als Hauptanwendung zum
Zugriff auf Data-Warehouse-Daten hat sich die multidimensionale Analyse mit Hilfe von
OLAP-Werkzeugen (Online Analytical Processing) durchgesetzt, eine explorative, interaktive
Analysetechnik, bei der die zu analysierenden Kennzahlen anhand von Dimensionen
organisiert sind. Die Dimensionen sind meist hierarchisch aufgebaut, d.h. sie beinhalten
verschiedene Aggregierungsstufen. Eine wichtige, sich schon aus der Historisierung der
Daten ergebende Dimension ist die Zeit. Die Navigation in OLAP-Anwendungen erfolgt mit
sog. Slice/Dice- und Drilldown/Rollup-Operationen.
Obwohl beide Begriffe in der Literatur oft vermischt werden, ist die Abgrenzung von Data
Warehousing als Integrationsansatz auf der einen und OLAP als multidimensionale
Analyseanwendung auf der anderen Seite von großer Bedeutung. Dies führt auch zu
unterschiedlichen Datenmodellen, da DWH-Datenmodelle aufgrund der historischen
Datenhaltung über Jahre stabil sein sollten, während sich (OLAP-) Analyseanforderungen
ändern können. Außerdem sollte ein Data Warehouse für Data Mining nutzbar sein, also auch
bisher unerkannte Analyseanforderungen unterstützen. Dieser Ansatz wird beispielsweise von
NCR Teradata1 und IBM propagiert und ist inzwischen allgemein anerkannt. Demnach wird
ein Data Warehouse mit klassischen ER-Methoden modelliert und relational gespeichert. Es
sei erwähnt, dass die saubere konzeptuelle Modellierung, besonders mit Blick auf die Anwendungsunabhängigkeit, als extrem wichtig und alles andere als trivial anzusehen ist. Der
Einsatz von branchenspezifischen Referenzmodellen und die Abbildung der Zeit sind nur
zwei Punkte, die weitere Untersuchung in der Forschung finden sollten.
1
Siehe auch unter http://www.teradata.com
46
Zur Unterstützung von OLAP-Anwendungen werden sog. OLAP Data Marts auf ein zentrales
Enterprise Data Warehouse aufgesetzt, die multidimensional modelliert und als Star- oder
Snowflake-Schemata durch physische Kopie oder SQL Views realisiert werden. Hier können
auch proprietäre multidimensionale Datenbanken (MOLAP Cubes) zum Einsatz kommen.
Abbildung 1 zeigt die beschriebene Architektur schematisch (angelehnt an [19]).
Statistics
Data Mining
Web Browser
Spreadsheet
Reporting
Web Server
OLAP Engine
Metadata
Repository
OLAP
Data Mart
Enterprise
Data
Warehouse
Integrator (ETL)
IMS
RDBMS
...
Others
Abbildung 1: Architektur eines Data-Warehouse-Systems
Der Rest dieses Beitrages gliedert sich wie folgt: Abschnitt 2 motiviert die
Sicherheitsproblematik in Data-Warehouse-Systemen und identifiziert zu adressierende
Sicherheitsaspekte. In Abschnitt 3 wird dann der Hauptaspekt, die Autorisierung und
Zugriffskontrolle, herausgegriffen und relevante Forschungsarbeiten in diesem Bereich
vorgestellt. Auch hierbei ist die angesprochene Trennung von Data Warehousing und OLAP
von Bedeutung, denn so lassen sich die Ansätze nach ihrer Sichtweise (Bottom-Up vs. TopDown) klassifizieren. In Abschnitt 4 schließlich wird eine im Rahmen des EUForschungsprojektes GOAL entwickelte Vorgehensweise zum Entwurf von OLAPSicherheitssemantiken vorgestellt. Abschnitt 5 schließt den Beitrag mit einer
Zusammenfassung und einem Ausblick ab.
47
2. Sicherheitsaspekte in Data-Warehouse-Systemen
Bereits in der Einleitung wurde der durch ein Data Warehouse aufgeworfenen
Sicherheitskonflikt angesprochen. Einerseits ist es das Ziel, die Daten so einfach wie möglich
zugreifbar zu machen, andererseits handelt es sich um hochsensible Daten, die zur
Entscheidungsunterstützung eingesetzt werden. Oft wird argumentiert, da es sich nur um
high-level Benutzer des Top-Managements handele, könne Sicherheit vernachlässigt werden.
Dies ist jedoch schon deswegen falsch, weil Data Warehouses inzwischen immer mehr auch
für untere Managementebenen und sogar für externe Benutzer (Kunden, Partner) mit Zugriff
über Portale und Intra-/Internet-Lösungen geöffnet werden. Eine kritische Betrachtung der
Sicherheitsproblematik ist also unabdingbar.
Die klassischen Anforderungen an die Sicherheit eines Informationssystems sind
Vertraulichkeit, Integrität, Verfügbarkeit. Wir konzentrieren uns hier auf die Vertraulichkeit,
d.h. den Schutz vor unberechtigtem Datenzugriff bzw. dem Ausspähen sensibler Daten.
Hierbei betrachten wir Aspekte der technischen Infrastruktur, der Datensammlung und des
Anwendungsdesigns, die zusammen die drei Säulen einer DWH-Sicherheitsstrategie
darstellen. Dies ist in Abbildung 2 schematisiert.
Anwendungsdesign
Authentifizierung,
Zugriffskontrolle, Auditing
Datensammlung
Privacy, Datenschutz
Technische Infrastruktur
Firewalls, Verschlüsselung
Sicherheits-
strategie
Abbildung 2: Drei Säulen einer DWH-Sicherheitsstrategie
Unter der Sicherheitsaspekten der technischen Infrastruktur verstehen wir speziell Fragen der
Netzwerksicherheit. Betrachtet man die in Abbildung 1 dargestellte Architektur, so fällt auf
den ersten Blick ins Auge, dass in einer Data-Warehouse-Umgebung enorm viel
Kommunikation stattfindet, sowohl die Quellen, als auch die Benutzer können auf
verschiedene Standorte verteilt sein. Die Nutzung unsicherer Netze (wie z.B. das Internet)
birgt dabei, wie in anderen verteilten Systemen auch, naturgemäß eine Reihe von
48
Sicherheitsrisiken. Es besteht die Gefahr von „Denial of Service“-Angriffen, der man mit
Firewalls begegnen kann. Vertraulichkeit lässt sich durch Verschlüsselung (z.B. durch Virtual
Private Networks) erreichen. Dieser wichtige Bereich ist also nicht zu vernachlässigen, es
herrscht aber kein (DWH-spezifischer) Forschungsbedarf.
Bei der Datensammlung sind speziell rechtlichen Fragestellungen, insbesondere der
Datenschutz zu nennen. Besonders in kundenzentrischen Data Warehouses mit dem Ziel des
Customer Relationship Managements [12], aber auch in anderen Bereichen, in denen
personenbezogene Daten analysiert werden, müssen Datenschutzbestimmungen beachtet
werden. Ein Grundproblem ist die in nationalen Datenschutzgesetzen und übergeordneten
EU-Regelungen festgeschriebene Zweckbindung: Daten dürfen eigentlich nur zu dem Zweck
verwendet werden, zu dem sie erhoben wurden. Das widerspricht dem Data-WarehouseGedanken, Daten zunächst einmal zu sammeln (Stichwort „Data Asset“), um dann später zu
sehen, welche Informationen man, beispielsweise mit Hilfe von Data Mining, aus ihnen
gewinnen kann. Der Datenschutzproblematik kann man z.T. durch Anonymisierung der Daten
begegnen. Eine umfassende Betrachtung dieser Thematik würde jedoch den Rahmen dieses
Beitrages sprengen.
Unter dem letzten Punkt des Anwendungsdesigns siedeln wir schließlich Problemstellungen
an, die die Anwendungen (d.h. den Zugriff) der Endbenutzer betreffen. Hier sind speziell
Benutzeridentifikation und -authentifizierung, Autorisierung und Zugriffskontrolle, sowie
Auditing zur Kontrolle und Überwachung der ersteren beiden zu nennen. Auch die
Benutzerauthentifizierung unterscheidet sich nicht von anderen Informationssystemen. Unser
Hauptaugenmerk legen wir auf Autorisierung und Zugriffskontrolle. Aufgrund der breiten,
heterogenen Benutzerstruktur ist es notwendig dedizierte Zugriffsrechte für unterschiedliche
Benutzergruppen definieren zu können. Wir konzentrieren uns hierbei auf den Zugriff durch
Endbenutzer. Die Administratorenzugriffe im Back-End-Bereich bedürfen natürlich ebenfalls
einer Kontrolle, diese ist aufgrund der überschaubaren Benutzerzahl jedoch meist weniger
problematisch.
3. Konzepte für Autorisierung und Zugriffskontrolle
Die Zugriffskontrolle gehört zu den Grundfunktionen, die vertrauenswürdige IT-Systeme
anbieten müssen, um Vertraulichkeit und Integrität von Informationen zu sichern. Betrachtet
wird einer Menge von:
− Objekten (z.B. Daten und Dokumente),
− Subjekten (z.B. Benutzer und Anwendungen), sowie
49
− möglichen Operationen (z.B. Lesen, Schreiben und Ausführen).
Während sich die Autorisierung mit der Verwaltung der Zugriffsrechte beschäftigt, die
definieren, welche Operationen ein bestimmtes Subjekt mit den zu schützenden Objekten
ausführen darf, dient die Zugriffskontrolle der Überprüfung dieser Berechtigungen zur
Laufzeit. Die Zugriffskontrolle baut demnach auf der Autorisierung auf. Wie in Abbildung 3
dargestellt, werden Berechtigungen von einer Autorisierungsinstanz vergeben bzw. entzogen.
Beim Versuch, auf ein geschütztes Objekt zuzugreifen, werden diese Rechte durch die
Zugriffskontrollfunktion geprüft.
Autorisierungsinstanz
besitzt/
kontrolliert
vergibt
Berechtigungen
Subjekt
Operation
Zugriffskontrollfunktion
Zugriff
erlaubt
Objekt
Zugriff verweigert
Abbildung 3: Grundprinzip der Autorisierung und Zugriffskontrolle
Der Autorisierung und Zugriffskontrolle kommt gerade in Data-Warehouse-Systemen eine
besondere Bedeutung zu. Zum einen sind, insbesondere in verteilten Umgebungen,
Datenlieferanten (z.B. autonome Fachabteilungen, Niederlassungen eines Unternehmens) nur
bereit, ihre Daten zur Speicherung in einem Data Warehouse zur Verfügung zu stellen, wenn
sie überblicken können, wer welchen Zugriff auf ihre Daten erhält. Zum anderen können
Anforderungen aber auch zentral bestimmt sein. Sie können sogar von den Benutzern selbst
stammen, denn bei der vorhandenen Datenflut wünschen Benutzer oft einen gefilterten
Zugang, der nur die für sie relevanten Daten enthält. Die Anforderungen an eine
Sicherheitspolitik für ein Data Warehouse können also von den unterschiedlichsten Seiten
kommen.
Dementsprechend finden sich auch in der Forschung unterschiedliche Ansätze für OLAP- und
Data-Warehouse-Sicherheit. Prinzipiell lassen sich zwei Sichtweisen unterscheiden:
50
− Der Bottom-Up-Ansatz sieht ein Data Warehouse als föderierte Datenbank. Es wird
versucht nicht nur die Daten durch Integrationsmechanismen zusammenzuführen,
sondern auch die Zugriffsrechte auf diese Daten von den Quellen her zu übernehmen.
− Der Top-Down-Ansatz geht den umgekehrten Weg. Er betrachtet in erster Linie die
(OLAP-) Anwendungen der Endbenutzer und entscheidet auf dieser Ebene wer
welchen Zugriff bekommen soll. Es erfolgt also ein expliziter Entwurf von
Zugriffsrechten.
Beide Ansätze haben ihre Daseinsberechtigung und sollen im Folgenden kurz vorgestellt
werden. Prinzipiell ist dabei ein grundsätzliches Problem analyseorientierter Systeme zu
beachten: die Abfragen und damit die Sensibilität der Abfrageergebnisse sind im Voraus oft
unbekannt. In operativ eingesetzten Transaktionssystemen sind die Datenbankanfragen durch
die Anwendung vorgegeben und wohlstrukturiert. OLAP-Systeme hingegen leben von Adhoc-Analysen und explorativer Navigation durch die Daten. Während man dort aber
wenigstens noch Standard-Berichte als Einstiegspunkte und übliche Navigationspfade
erkennen kann, ist die Einschätzung der Sensibilität der Ergebnisse bei Data Mining, wo es ja
gerade um die Suche nach neuen unbekannten Mustern in den Daten geht, praktisch
unmöglich.
3.1. Bottom-Up-Ansatz: Ableitung von Zugriffsrechten
Ableitung von Zugriffsrechten
Wie bereits erwähnt, verfolgt der Bottom-Up Ansatz das Ziel der Ableitung der
Zugriffsrechte von den Datenquellen, also eine Integration nicht nur der Daten selbst, sondern
auch der Sicherheitspolitiken (s. Abbildung 4).
Enterprise
Data
Warehouse
Integrator (ETL)
IMS
RDBMS
...
Others
Abbildung 4: Vorgehensweise beim Bottom-Up-Ansatz
51
In diese Richtung gehen auch Arbeiten zu Sicherheit in Datenbankföderationen (z.B. [7], [3]).
Es gilt, die auf den Datenquellen definierten Zugriffsrechte zu integrieren und auf Ebene des
Data Warehouse zu implementieren. Da die Mechanismen relationaler Datenbanken
beschränkt sind und vor allem keine Ableitungsregeln vorsehen, werden Erweiterungen der
SQL-Sicherheitsmechanismen vorgeschlagen (siehe dazu [17] und [18]). Vertreter dieser
Richtung fordern eine Entkopplung von der physischen Ebene. Autorisierungen sollen sich
auf den Informationsgehalt und nicht auf physische Tabellen oder andere Speicherstrukturen
beziehen.
Neben technischen Schwierigkeiten gibt es jedoch auch prinzipielle Probleme mit dem
Bottom-Up-Ansatz. Die Benutzer im analytischen Bereich sind i.d.R. nicht die gleichen, wie
im operativen Umfeld (Entscheider, „Knowledge Worker“ vs. Sachbearbeiter). Die
Administratoren der Quellen müssten also die Rollen/Benutzer des Data Warehouse kennen
und explizit berücksichtigen. Desweiteren geht der Ansatz von einer dezentralen
Entscheidung über die DWH-Zugriffsrechte aus. Diese Annahme ist in einigen Fällen mit
autonomen Datenlieferanten möglicherweise korrekt (man denke beispielsweise an Firmen
die Ihre Daten zu Marktforschungszwecken zur Verfügung stellen, oder an öffentliche
Einrichtungen), im Regelfall wird jedoch die Unternehmensleitung zentral über den Zugriff
auf die Unternehmensdaten zu entscheiden haben.
3.2. Top-Down-Ansatz: Entwurf von Zugriffsrechten
Letztlich geht es bei Autorisierung und Zugriffskontrolle doch um die Frage, welche
Anfragen den Endbenutzern schließlich gestattet werden. Diese Frage lässt sich bei einem
Bottom-Up-Ansatz jedoch zum Teil nur schwer beantworten, da sich die Autorisierungen auf
den (physischen, relationalen) Datenspeicher beziehen und von einer multidimensionalen
OLAP-Anwendung zu weit entfernt sind. Dies ist besonders problematisch, da
Zugriffseinschränkungen Abfrageergebnisse verfälschen und so zu falschen Entscheidungen
führen können. Daher werden die Anforderung an eine Zugriffskontrolle oft aus
Anwendungs- (OLAP-) Sicht definiert.
52
Web Browser
Spreadsheet
Reporting
OLAP Engine
Entwurf von Zugriffsrechten
Web Server
OLAP
Data Mart
Abbildung 5: Vorgehensweise beim Top-Down-Ansatz
Betrachtet man die Sicherheitsproblematik also aus Sicht der Anwendungen, ergibt sich ein
Top-Down-Ansatz, bei dem explizit OLAP-Zugriffsrechte (Benutzersichten) unter
Verwendung multidimensionaler Konstrukte definiert werden (s. Abbildung 5). So lässt sich
beispielsweise auch der Zugriff auf unterschiedliche Aggregationsebenen regeln. Eine frühe
Arbeit, die sich mit Autorisierung auf OLAP-Ebene beschäftigt ist [10]. Dort wird ein auf
AMAC (Adapted Mandatory Access Controls) basierender Ansatz vorgestellt. Ein späterer
Beitrag der gleichen Arbeitsgruppe [8] schlägt die Verwendung von Metadaten zur
Beschreibung der Autorisierungen vor. Dieser Vorschlag wird in [4] wieder aufgegriffen und
konkretisiert.
Während die Notwendigkeit der Formulierung von Zugriffseinschränkungen anfangs von
Herstellern noch in Frage gestellt, oder die Umsetzung auf die zur Speicherung der Daten
verwendete relationale Datenbank „abgeschoben“ wurde, bieten kommerzielle Produkte heute
recht ausgereifte Zugriffskontrollmechanismen auf OLAP-Ebene an. Die Produkte verwenden
jedoch sehr proprietäre Verfahren zur Implementierung der Zugriffseinschränkungen, die zu
Entwurfs- und Dokumentationszwecken eher ungeeignet sind. Eine Übersicht findet sich in
[14]. Aufgrund der Sensibilität der Daten und der Gefahr der Ergebnisverfälschung durch zu
restriktive Autorisierungen ist jedoch bei dem Entwurf solcher Zugriffsrechte besondere
Sorgfalt angesagt. Hierzu haben wir eine Vorgehensweise entwickelt, die im folgenden
Abschnitt näher erläutert werden soll.
4. Ein Ansatz zum Entwurf von OLAP-Sicherheit
Die im Folgenden vorgestellte Vorgehensweise zum Entwurf von OLAPSicherheitssemantiken entstand im Rahmen des Forschungsprojektes GOAL (Geographic
53
Information
Online
Analysis)2,
das sich die Integration von geographischen
Informationssystemen (GIS) und Data-Warehouse-Techniken zum Ziel gesetzt hat. Zwei
Pilotanwendungen (A1 und A2) wurden für das Projekt definiert. Anwendung A1 untersucht
Ticket-Verkäufe in Schlössern und anderen Denkmälern der Tschechischen Region
Südböhmen (vgl. [11]). Anwendung A2 beschäftigt sich mit Trinkwasserversorgung und verbrauch in einer westböhmischen Region nahe der Stadt Sokolov, CZ. Im weiteren Verlauf
dieses Beitrages wird Anwendung A1 als Fallstudie verwendet.
4.1. OLAP-Entwurf mit ADAPTed UML
Da, wie bereits erwähnt, bei einem Top-Down-Ansatz Zugriffsrechte auf OLAP-Ebene
definiert werden, muss der Entwurf mit dem OLAP-Anwendungsentwurf Hand in Hand
gehen. Im Rahmen des Entwurfes einer multidimensionalen OLAP-Anwendung gilt es, die
Fakten/Kennzahlen und Dimensionen mit ihren Hierarchien (sprich Navigationspfade) zu
modellieren. Dabei gibt es in Bezug auf multidimensionale Modelle und grafische
Entwurfsnotationen viele Vorschläge (z.B. M/ER [21] oder DFM [5]), es ist aber kein
Standard in Sicht. ADAPTed UML kombiniert daher verschiedene Ansätze: sie ist UMLbasiert und profitiert damit von breiter Unterstützung durch Entwurfswerkzeuge wie z.B.
Rational Rose3, verwendet zur intuitiveren Darstellung aber statt textueller Stereotypen
Symbole aus ADAPT4.
Die Verwendung von UML hat weiterhin den Vorteil, dass alle in UML vorhandenen
Erweiterungsmöglichkeiten verwendet werden können, z.B. UML Constraints zur
Unterbringung zusätzlicher Semantik (z.B. Aggregatfunktionen der Kennzahlen, oder eben
für Sicheheitssemantiken, wie im nächsten Abschnitt dargestellt). ADAPTed UML ist durch
ein Metamodell definiert, welches zum einen das multidimensionale Modell und zum
anderen dessen graphische Repräsentation beschreibt. Auf eine ausführliche Darstellung wird
im Rahmen dieses Beitrages verzichtet, hierzu sei auf [15] verwiesen.
Abbildung 6 zeigt beispielhaft ein OLAP-Datenmodell aus dem genannten GOAL-Projekt. Es
geht um die Analyse von Besucherzahlen und Ticketverkäufen in Schlössern in Südböhmen
(Tschechische Republik). Es existieren zwei separate Würfel mit unterschiedlichen
Kennzahlen. Der People-Würfel speichert Besucherzahlen und -umsätze, der Services-Würfel
2
Das Projekt GOAL wurde in einer internationalen Arbeitsgruppe im Rahmen des INCO-COPERNICUSProgramms der Europäischen Union unter Projektnr. 977091 durchgeführt. Die beteiligten Partner sind
Technische Universtät Wien (A), Czech Technical University in Prag (CZ), Universität Essen (D), Technical
University Košice (SK), CertiCon a.s. (CZ) und ASP Systems s.r.o. (CZ).
3 Siehe unter http://www.rational.com/products/rose/
4 ADAPT ist ein Warenzeichen der Symmetry Corp., San Rafael, CA, USA, siehe unter
http://www.symcorp.com
54
beinhaltet Daten über von den Besuchern erworbene Dienstleistungen (z.B. eine Erlaubnis,
Fotos zu machen). Dabei existieren die Fakten des People-Würfels in der Granularität Tour,
während die Fakten des Services-Würfel weniger detailliert (auf Objekt-Ebene) vorliegen.
{ }
Year
{ }
{ }
Service group
{ }
Week
Day of week
{ }
Month
{ }
Service
{ }
Payment type
{ }
Day
Services
Count
Revenue
{ }
{ }
Region
{ }
Part of day
Object
{ }
People
Tour
Count
Revenue
Waiting
Capacity
{ }
Category
{ }
Language
{ }
Group type
{ }
Payment type
Abbildung 6: Beispielmodell in ADAPTed-UML-Notation
In relationalen Datenbanken kennt man zwei Abstraktionsebenen: die Schemaebene und die
Instanzebene. Diese gibt es auch im OLAP-Umfeld. Zur Schemaebene (z.T. auch MetadatenEbene genannt) gehören die oben genannten Konstrukte wie Würfel, Kennzahl und
Hierarchieebene. Im Gegensatz zum relationalen Fall ist es bei OLAP jedoch sinnvoll, die
Instanzebene noch einmal zu trennen. Man unterscheidet hier die Instanzen der Dimensionen
und die Fakten, die eigentlich zu analysierenden Kennzahlen. Diese Unterscheidung wird
auch im nächsten Abschnitt noch einmal aufgegriffen. Aus Modellierungssicht ist es sinnvoll,
die Instanzen weitestgehend statischer Dimensionen bereits zur Entwurfszeit zu betrachten,
hierzu wurde ADAPTed UML um den Diagrammtyp „Dimensionsbaum“ erweitert.
55
{ }
All
{ }
{ }
Region 1: Region
{ }
{ }
Cervena Lhota: Object
{ }
Okruh 1: Tour
Capacity = 28
Region 2: Region
{ }
Hluboka: Object
{ }
Bazilika sv. J.: Tour
Capacity = 50
{ }
Trasa 1: Tour
Capacity = 50
{ }
Hor. Tyn: Object
{ }
Trasa 2: Tour
Capacity = 50
{ }
Hrad: Tour
Capacity = 10
Rozmberk: Object
{ }
Kuchyne: Tour
Capacity = 10
{ }
Vecerni okruh: Tour
Capacity = 30
Abbildung 7: Dimensionsbaum der Geographiedimension
Abbildung 7 zeigt die Instanzen der Geographiedimension, zur Vereinfachung und aus
Platzgründen ist nur ein Ausschnitt dargestellt. Obwohl es sich um Instanz- (nicht Schema-)
Informationen handelt, macht eine Betrachtung zur Entwurfszeit Sinn. Die Daten dienen in
der OLAP-Anwendung wie das Schema der Navigation und sind im Vergleich zu den zu
analysierenden Fakten/Kennzahlen relativ statisch.
4.2. OLAP-Sicherheit und MDSCL
Im GOAL-Projekt wurden durch die Anwenderpartner verschiedene mögliche
Benutzergruppen mit eingeschränkten Sichten auf das o.a. Datenmodell identifiziert. In der
ersten Phase entstanden beispielsweise die folgenden Beschreibungen:
− „Ein Object Manager kann beliebige Informationen seines Objektes abfragen, für
andere Objekte gilt ein eingeschränkter Zugriff.“
− „Das Regional Institute hat ähnlichen Zugriff wie ein Object Manager, allerdings alle
untergeordneten Objekte betreffend.“
− „Service Provider erhalten einen eingeschränkten, vertraglich vereinbarten Zugriff.“
− ...
Aber was bedeuten diese Aussagen letztlich für die OLAP-Anwendung? Aus den Zitaten wird
schnell klar, dass ohne ein semantisches OLAP-Modell und eine klare Sprache zur
Beschreibung der Autorisierungen unterschiedliche Benutzergruppen nur schwer eindeutig
definiert werden können. Es besteht also die Notwendigkeit zum Entwurf bzw. zur
Modellierung der Zugriffsrechte. Ein früher Ansatz zur Modellierung von
Sicherheitssemantiken findet sich in [13].
56
Die drei Abstraktionsebenen im OLAP-Bereich (Metadaten/Schema, Dimensionselemente,
Fakten/Zellen) wurden bereits genannt. Auch Autorisierungen lassen sich auf diesen drei
Ebenen unterscheiden. Dimensionselemente stellen die Instanzdaten der Dimensionen dar,
dienen aber auch der Navigation und sind relativ statisch. Autorisierungen auf Schema- und
Dimensionselementebene lassen sich durch Einschränkung der Navigation umsetzen, d.h.
unerlaubte Abfragen werden vermieden. Komplexe Autorisierungen (auf Fakt-/Zellebene)
führen zu zurückgewiesenen Abfragen oder unvollständigen Abfrageergebnissen. Diese
Einteilung ist in Abbildung 8 dargestellt.
Autorisierungen
auf Fakt-/Zellebene
Autorisierungen auf
Dimensionselementebene
Autorisierungen auf Metadaten-/
Schemaebene
Abbildung 8: OLAP-Autorisierungen auf drei Abstraktionsebenen
Zur Beschreibung der Autorisierungen haben wir eine Sprache, die sog. MDSCL
(Multidimensional Security Constraint Language) entwickelt. Die Syntax ist angelehnt an
MDX (Multidimensional Expressions)5 jedoch prinzipiell unabhängig von bestimmten
OLAP-Produkten. Eine Übersetzung der Autorisierungen in unterschiedliche Zielsysteme ist
möglich, konkret haben wir ausführliche Experimente mit Microsoft Analysis Services und
MicroStrategy6 gemacht.
Unser Sicherheitsmodell basiert auf der Annahme einer zentralen Sicherheitspolitik (TopDown-Ansatz). Die Zugriffseinschränkungen werden als Autorisierungsconstraints definiert,
diese können prinzipiell positiv (explizite Erlaubnisse) oder negativ (explizite Verbote) sein.
Unser Modell basiert auf einer offenen Sicherheitspolitik (d.h. Zugriff wird gewährt, soweit
5
Verwendung in den Analysis Services des Microsoft SQL Server und bei OLE DB for OLAP, einer
Schnittstelle zwischen OLAP Server und Client
6 Siehe unter http://www.microsoft.com/sql/ bzw. http://www.microstrategy.com
57
nicht explizit verboten, man spricht auch von „Open World Policy“) mit negativen
Autorisierungen. Dies entspricht der offenen Natur von OLAP-Systemen und den
Sicherheitsmechanismen der meisten betrachteten OLAP-Produkte. Durch die negativen
Autorisierungen wäre die Semantik der Vererbung in Rollenhierarchien unklar. Daher
verzichten wir in unserem Modell darauf und gehen von einfachen (nicht-hierarchischen)
Rollen [20] als Sicherheitssubjekte aus. Außerdem berücksichtigen wir nur Lesezugriff,
schreibender Zugriff (z.B. zur Speicherung von Plandaten oder für „What-If“-Analysen) ist in
Mehrbenutzerumgebungen unüblich.
Die negativen Autorisierungen werden in MDSCL, in Anlehnung an das „CREATE CUBE“Kommando von MDX, durch „HIDE“-Kommandos ausgedrückt. Für eine detaillierte
Beschreibung von MDSCL sei auf [16] verwiesen, hier soll eine beispielhafte Betrachtung
genügen. So wurde beispielsweise die Benutzersicht der bereits erwähnten Rolle der Service
Provider durch folgende MDSCL-Ausdrücke konkretisiert:
HIDE CUBE People FOR ROLE [Service Provider]
HIDE MEASURE Services.Revenue FOR ROLE [Service Provider]
In diesem Fall liegen ausschließlich Autorisierungen auf Metadaten-/Schemaebene vor. Als
eingeschränkte Benutzersicht ergibt sich das in Abbildung 9 dargestellte ADAPTed-UMLDiagramm. Die Autorisierungen resultieren in einer eingeschränkten Navigation: es wird nur
der Services-Würfel und darin nur die Count-Kennzahl angeboten.
58
{ }
Year
{ }
{ }
Service group
{ }
Week
{ }
Day of week
Month
{ }
Service
{ }
Payment type
{ }
Day
Services
Count
{ }
{ }
Region
{ }
Part of day
Object
Abbildung 9: Eingeschränkte Benutzersicht der Rolle Service Provider
Während hier, wie erwähnt, ausschließlich Autorisierungen auf Schema-/Metadatenebene
vorliegen, wird bei der folgenden Spezifikation der Rolle Hluboka Manager auch eine
Filterung der Dimensionselemente vorgenommen:
HIDE SLICE WHERE Object != "Hluboka" FOR ROLE [Hluboka Manager]
HIDE LEVEL Region FOR ROLE [Hluboka Manager]
Durch die vorgenommene Einschränkung schrumpft die Geographiedimension auf den in
Abbildung 10 dargestellten Teil zusammen. Dies führt dazu, dass Benutzer mit dieser Rolle
ausschließlich zum Objekt Hluboka und den zugehörigen Touren navigieren können. Nicht
autorisierte Abfragen werden somit ebenfalls vermieden.
{ }
Hluboka: Object
{ }
Bazilika sv. J.: Tour
Capacity = 50
{ }
Trasa 1: Tour
Capacity = 50
{ }
Trasa 2: Tour
Capacity = 50
Abbildung 10: Eingeschränkte Geographiedimension der Rolle Hluboka Manager
59
Schließlich soll noch beispielhaft eine Rolle mit Autorisierungen auf Fakt-/Zellebene
betrachtet werden:
HIDE LEVEL [Part of day] WHERE Object != "Hrobka"
FOR ROLE [Hrobka Manager]
HIDE LEVEL Day WHERE Object != "Hrobka"
HIDE LEVEL Month WHERE Object != "Hrobka"
Eine komplexe Rollendefinition wie hier (der Manager von Hrobka soll für sein Schloss
Detaildaten, für die anderen nur Aggregate auf Jahresebene sehen können) lässt sich
graphisch nicht mehr durch Ausblenden von Schema- oder Dimensionselementen darstellen.
Eine solche Zugriffsbeschränkung lässt sich auch nicht mehr durch eingeschränkte Navigation
erreichen. Hier werden Abfragen u.U. zurückgewiesen oder unvollständige Abfrageergebnisse
ausgegeben. Letzteres ist natürlich problematisch, da es zu Fehlinterpretationen der Nullwerte
kommen kann.
{ }
Year
{ }
{ }
Service group
{ }
Week
Day of week
{ }
Month
{ }
Service
{ }
Payment type
{ }
Day
Services
Count
Revenue
{ HIDE MEASURE
Services.Revenue FOR
ROLE [Service Provider] }
{ HIDE LEVEL Region FOR
ROLE [Hluboka Manager] }
{ HIDE CUBE People FOR
ROLE [Service Provider] }
{ }
{ }
Region
{ }
Part of day
Object
{ }
People
Tour
Count
Revenue
Waiting
Capacity
{ HIDE SLICE WHERE
Object != "Hluboka" FOR
ROLE [Hluboka Manager] }
{ }
Category
{ }
Language
Abbildung 11: OLAP-Modell mit MDSCL-Constraints
60
{ }
Group type
{ }
Payment type
Wie bereits erwähnt können MDSCL-Ausdrücke auch mit Hilfe von UML-Constraints in das
ADAPTed-UML-Modell eingebracht werden, um die Sicherheitspolitik zu dokumentieren.
Abbildung 11 zeigt die dargestellten Autorisierungen der Rollen Service Provider und
Hluboka Manager.
5. Zusammenfassung und Ausblick
Dieser Beitrag stellt eine Analyse der Sicherheitsproblematik in Data-Warehouse-Systemen
dar. Nach einer Motivation und Fokussierung auf den Bereich der Autorisierung und
Zugriffskontrolle haben wir zwei unterschiedliche Forschungsansätze vorgestellt, mit denen
Fragen der Data-Warehouse-Sicherheit bearbeitet werden können: den Bottom-Up-Ansatz zur
Ableitung von Zugriffsrechten für das Data Warehouse von den Datenquellen und den TopDown-Ansatz zum expliziten Entwurf von OLAP-Zugriffsrechten. Zu letzterem haben wir
eine auf ADAPTed UML und MDSCL basierende Methodik vorgestellt.
Beide Ansätze haben ihre Einschränkungen und Probleme. Ein Top-Down-Ansatz kann sich
beispielsweise nur auf einzelne OLAP-Anwendungen beziehen. Ein Integration von BottomUp- und Top-Down-Ansatz könnte also Sinn machen, ist aber nicht einfach, da
unterschiedliche Datenmodelle (relational vs. multidimensional) und Sicherheitspolitiken
(offen vs. geschlossen) zum Einsatz kommen. Hier könnten Arbeiten im Bereich
konzeptueller DWH-Modellierung als Bindeglied helfen. Da sowohl die relationale
Umsetzung eines Data Warehouse, als auch OLAP-Anwendungen darauf beruhen.
Nicht näher betrachtet haben wir außerdem die Kontrolle statistischer Inferenzen. Die Inferenzproblematik bezieht sich auf indirekten Datenzugriff und kann beispielsweise entstehen,
wenn neben den normalen Navigationspfaden eine parallele Klassifikationsmöglichkeit der
Fakten existiert [22], oder wenn Zugriff auf aggregierte Daten erlaubt wird, nicht aber auf
Detaildatensätze. Durch geschickte Kombination mehrerer Aggregatabfragen kann dann u.U.
auf Detaildaten geschlossen werden, die direkt nicht zugreifbar wären. Man spricht von sog.
Tracker-Angriffen [2]. Ein möglicher Ansatz wäre eine Analyse der Audit-Logs um
potentielle Angriffe zu erkennen (vgl. Intrusion-Detection-Systeme), ggf. in Echtzeit. Der
dafür nötige Aufwand ist jedoch sicherlich nur für Projekte im Hochsicherheitsbereich
gerechtfertigt.
61
LITERATUR
[1] CHAUDHURI, S., DAYAL, U.: An Overview of Data Warehousing and OLAP Technology. ACM
SIGMOD Record, Volume 26, Issue 1, März 1997.
[2] DENNING, D.E., SCHLÖRER, J.: A Fast Procedure for Finding a Tracker in a Statistical Database. ACM
Transactions on Database Systems (TODS), Volume 5, Number 1, March 1980.
[3] ESSMAYR, W., KASTNER, F., PERNUL, G., PREISHUBER, S., TJOA, A M. Authorization and Access
Control in IRO-DB. Proc. Int. Conf. on Data Engineering (ICDE'96), New Orleans, LA, February 1996.
[4] ESSMAYR, W., WEIPPL, E., WINIWARTER, W., MANGISENGI, W., LICHTENBERGER, F., An
Authorization Model for Data Warehouses and OLAP. Workshop On Security In Distirbuted Data Warehousing,
in conjunction with 20th IEEE Symposium on Reliable Distributed Systems (SRDS'2001), October 28-29, 2001,
New Orleans, USA.
[5] GOLFARELLI, M., MAIO, D., RIZZI, S.: The Dimensional Fact Model: A Conceptual Model for Data
Warehouses. International Journal of Cooperative Information Systems (IJCIS) Volume 7, Numbers 2-3, June &
September 1998.
[6] INMON, W.H.: Building the Data Warehouse. Wiley & Sons, New York et al., 1996.
[7] JONSCHER, D., DITTRICH, K.R.: An Approach for Building Secure Database Federations. Proc. 20th Int.
Conf. on Very Large Databases (VLDB), Santiago, Chile, 1994.
[8] KATIC, N., QUIRCHMAYR, G., SCHIEFER, J., STOLBA, M., TJOA, A.M.: A Prototype Model for Data
Warehouse Security Based on Metadata. In Proc. DEXA 98, Ninth International Workshop on DEXA, Vienna,
Austria, August 26-28, 1998.
[9] KIMBALL, R.: Hackers, Crackers, and Spooks – Ensuring that your data warehouse is secure. In DBMS
Magazine, April 1997.
[10] KIRKGÖZE, R., KATIC, N., STOLDA, M., TJOA, A.M.: A Security Concept for OLAP. Proc. of the 8th
International Workshop on Database and Expert Systems Applications (DEXA '97), Toulouse, France,
September 1-2, 1997.
[11] KOUBA, Z., MIKSOVSKY, P., MATOUSEK, K., ZACH, P.: Application A1 Specification. GOAL
Technical Report TR8, INCO-COPERNICUS Project No. 977091, March 1999.
[12] KURZ, A.: Data Warehousing – Enabling Technology. MITP-Verlag, Bonn, 1999.
[13] PERNUL, G., WINIWARTER, W., TJOA A.M.: The Entity-Relationship Model for Multilevel Security. In
Proc. 12th International Conference on the Entity-Relationship Approach (ER'93), Arlington, Texas, USA,
Dezember 15-17, 1993.
[14] PRIEBE, T., PERNUL, G.: Towards OLAP Security Design – Survey and Research Issues. Proc. Third
ACM International Workshop on Data Warehousing and OLAP (DOLAP 2000), McLean, VA, USA, November
2000.
[15] PRIEBE, T., PERNUL, G.: Metadaten-gestützer Data-Warehouse-Entwurf mit ADAPTed UML. Proc. 5.
Internationale Tagung Wirtschaftsinformatik (WI 2001), Augsburg, September 2001.
[16] PRIEBE, T., PERNUL, G.: A Pragmatic Approach to Conceptual Modeling of OLAP Security. Proc. 20th
International Conference on Conceptual Modeling (ER 2001), Yokohama, Japan, November 2001.
[17] ROSENTHAL, A., SCIORE, E., DOSHI, V.: Security Administration for Federations, Warehouses, and
other Derived Data. In Proc. IFIP WG 11.3 Working Conference on Database Security, Seattle, WA, USA.
62
[18] ROSENTHAL, A., SCIORE, E.: View Security as the Basis for Data Warehouse Security. Proceedings of
the International Workshop on Design and Management of Data Warehouse (DMDW’2000), Sweden, June
2000.
[19] SAMTANI, S., MOHANIA, M., KUMAR, V., KAMBAYASHI, Y.: Recent Advances and Research
Problems in Data Warehousing. Proc. of the International Workshop on Data Warehousing & Data Mining,
Mobile Data Access, and New Database Technologies for Collaborative Work Support & Spatio-Temporal Data
Management, Singapore, November 19-20, 1998.
[20] SANDHU, R.S., COYNE, E. J., FEINSTEIN, H.L., YOUMAN, C.E.: Role-Based Access Control Models.
IEEE Computer, Vol. 29, Number 2; February 1996.
[21] SAPIA, C., BLASCHKA, M., HÖFLING, G., DINTER, B.: Extending the E/R Model for the
Multidimensional Paradigm. In Kambayashi, Y. et. al. (Hrsg.), Advances in Database Technologies, LNCS Vol.
1552, Springer, 1999.
[22] STEGER, J., GÜNZEL, H.: Identifying Security Holes in OLAP Applications. To appear in Proc.
Fourteenth Annual IFIP WG 11.3 Working Conference on Database Security, Schoorl, Netherlands, August 2123, 2000.
Torsten Priebe studierte an der Universität Essen Wirtschaftsinformatik und erlangte
2000 den Abschluss als Diplom-Wirtschaftsinformatiker. Er arbeitete seit 1999 (seit
2000 als wissenschaftlicher Mitarbeiter) am Lehrstuhl für Wirtschaftsinformatik und
Informationssysteme an der Universität Essen und war an diversen internationalen
Forschungsprojekten der Arbeitsgruppe beteiligt. Zusammen mit Prof. Günther Pernul
wechselte er im Oktober 2002 an die Universität Regensburg. Seine
Forschungsinteressen liegen hauptsächlich in den Bereichen Data Warehousing und
OLAP, Wissensmanagement, Semantic Web und Informationssicherheit. In diesen
Bereichen hat er Publikationen in internationalen Konferenzreihen und war an einem
Lehrbuch zu Data Warehousing beteiligt. Desweiteren arbeitet Torsten Priebe als
selbständiger IT-Berater, hauptsächlich im Datenbankbereich, und besitzt
verschiedene Industriezertifikate.
Günther Pernul studierte an der Universität Wien Wirtschaftsinformatik, Promotion
1989 mit einer Arbeit über Entwurfsstrategien für relationale Datenbanken. Nach
einem längereren Forschungsaufenthalt in den USA, zuerst am Database Systems
Research and Development Center der University of Florida und später dann am
College of Computing des Georgia Institute of Technology in Atlanta erfolgte Ende
1993 seine Habilitation am Institut für Angewandte Informatik und
Informationssysteme der Universität Wien mit einer Arbeit zu Fragestellungen der
Datenbanksicherheit. Kurz danach erreichten ihn Rufe an die BTU Cottbus, die
Universität Magdeburg und die Universität Essen. Von 1995-2002 war er Universitätsprofessor für Wirtschaftsinformatik an der Universität Essen, an der er auch
als Dekan der Fakultät für Wirtschaftswissenschaften wirkte. Seit Oktober 2002 hat
Günther Pernul den Lehrstuhl für Wirtschaftsinformatik I an der Universität Regensburg inne. Günther Pernul
ist Autor bzw. Herausgeber von fünf Büchern und hat zahlreiche wissenschaftliche Publikationen in
internationalen Journalen und Konferenzbänden verfasst. Prof. Pernul ist ständiges Mitglied im
Programmkomitee mehrerer internationaler wissenschaftlicher Konferenzreihen, Mitherausgeber einer
Buchreihe „Electronic Commerce“ und Mitglied im Steering Board der Communications and Multimedia
Security
Konferenzreihe.
63
64
Fachbeitrag
65
66
Todsünden des Data Warehousing
Das Data-Warehouse-Konzept hat sich als unverzichtbarer Bestandteil moderner Systeme zur Entscheidungsunterstützung am Markt etabliert. Der Synergieeffekt eines Data Warehouse als einheitlicher und
integrierter Datenpool für fortschrittliche Data-Mining-Applikationen, CRM-Systeme, OLAP-Analysen
oder auch klassische Berichtswerkzeuge ist unumstritten. Im vorliegenden Artikel werden als Ergebnis
mehrjähriger Projekterfahrung wesentliche Fallstricke („Todsünden“) bei der Entwicklung eines DataWarehouse-Systems skizziert, um Projektbeteiligten wie auch Entscheidern ein kompaktes Hilfsmittel an
die Hand zu geben, Rahmenbedingungen für ein erfolgreiches Data-Warehouse-Vorhaben abzustecken.
Dr. Michael Böhnlein, Dr. Andreas Bauer
T-Systems Nova GmbH
1 Einführung
Um den unternehmerischen Erfolg
und damit den Bestand einer Unternehmung auf Dauer zu sichern, spielen nicht nur kurzfristige Lenkungsaktivitäten innerhalb des Unternehmens,
sondern vor allem auch Gestaltungsaktivitäten mit häufig mittel- bis langfristiger Wirkung eine zunehmend
wichtige Rolle. Die hierzu notwendigen Entscheidungen setzen eine adäquate Informationsgrundlage voraus,
um rechtzeitig und flexibel auf Veränderungen und sich daraus ergebenden zukünftigen Chancen bzw. Bedrohungen in der Wettbewerbsumwelt
reagieren zu können.
Ein derzeit viel diskutierter Ansatz
zur Verbesserung der unternehmensweiten Informationsversorgung stellt
das Data-Warehouse-Konzept dar.
Ein Data Warehouse erhebt den Anspruch, eine unternehmensweite, integrierte und konsistente Datenbasis
getrennt von den Datenbeständen operativer Systeme des jeweiligen Tagesgeschäfts zu schaffen.
Laut Aussagen der Meta Group führen jedoch nur 30 Prozent aller DataWarehouse-Projekte zum Erfolg,
während 50 Prozent die gestellten
Erwartungen nur zum Teil erfüllen.
Die verbleibenden 20 Prozent hingegen scheitern völlig. Diese unbefriedigende Situation wird dahingehend
weiter
verschärft,
dass
DataWarehouse-Vorhaben i.d.R. sehr kostenintensiv sind. Einer Umfrage des
Data Warehousing Institute (TDWI)
zufolge sind Durchschnittskosten in
Höhe von ca. 1,2 Millionen Dollar für
das erste Projektjahr aufzuwenden.
Ziel des vorliegenden Artikels ist es,
Problembewusstsein für mögliche
Bedrohungen im Rahmen eines DataWarehouse-Projektes zu wecken. Diese „Todsünden“ im Sinne von Projektrisiken sollten bereits im Vorfeld
eines
Data-Warehouse-Vorhabens,
soweit möglich, eingehend beleuchtet
und reflektiert werden. Abbildung 1
vermittelt einen Überblick über die
sieben zentralen Themenbereiche für
Todsünden, die uns in unserer langjährigen Projekterfahrung im DataWarehouse-Umfeld immer wieder begegnet sind. Diese Problembereiche
werden in der betrieblichen Praxis
leider häufig zu Unrecht stark unterschätzt. Streng genommen kann man
anstelle von Todsünden auch von
„Unterlassungssünden“ sprechen.
Wie Abbildung 1 zeigt, überwiegen
sog. „weiche Faktoren“ bei den Problembereichen, wie z.B. das Projektteam oder die Informationsbedarfs-
analyse. Technologische Probleme
sind meist leichter beherrschbar.
Ziel des Artikels ist es nicht, allgemeingültige Lösungsvorschläge für
die Todsünden innerhalb der jeweiligen Problembereiche zu skizzieren.
Vielmehr soll Grundwissen zur Schärfung des eigenen Problembewusstseins vermittelt werden, um die vorgestellten Bereiche bereits selbst
kompetent und frühzeitig in die eigenen Überlegungen einbeziehen zu
können. Darauf aufbauend werden
Lösungsstrategien vorgeschlagen, um
die Chancen für ein erfolgreiches Data-Warehouse-Vorhaben zu erhöhen.
Im folgenden werden die einzelnen
Themenbereiche und die mit ihnen
verbundenen Todsünden detailliert
betrachtet.
Abbildung 1: Todsünden des Data Warehousing
•
Aus Unsicherheit, welche konkreten Ziele im Fokus des Projekts stehen sollen, wird der große „Wurf“ versucht, der alle
Probleme der Unternehmung auf
einmal löst. Diese „Big Bang“
Herangehensweise führt in der
Regel zu einer enormen Komplexität, die das Projektteam gänzlich überfordert.
Eine Unternehmung sollte darüber hinaus nicht der Illusion unterliegen, ihr Data-WarehouseVorhaben auf der „grünen Wiese“
durchführen zu können.
Vielmehr muss das Data Warehouse in die bestehende Anwendungssystemlandschaft des Unternehmens integriert werden.
Entscheidend beim Aufbau einer umfassenden Data-Warehouse-Lösung
ist eine ganzheitliche Konzeption unter Berücksichtigung einer langfristigen Perspektive. Hierbei ist das viel
zitierte Motto „think big, start small“
zu berücksichtigen.
Vertikale Integration
Entscheidungs-
unterstützungssysteme
Administrations- u. Dispositionssysteme
e
he m
l i c st e
eb s y
tri ns
Be atio
m
or
Inf
•
Um schnelle Erfolge zu realisieren werden sukzessive Entscheidungs-„Inseln“ in Form von
voneinander isolierten Data Marts
aufgebaut.
Um
Inselübergreifende Auswertungen zu
ermöglichen, werden ggf. mehr- •
stufig Daten zwischen diesen Lösungen ausgetauscht. Inmon, der
Schöpfer des „Data-Warehouse“Gedankens, spricht in diesem Zusammenhang von „Spinnennetzen“, deren gegenseitige Abhängigkeiten kaum mehr entflochten
werden können.
Management-
unterstützungssysteme
e
•
e
ch t em
tis ys
al y ss
An tion
ma
or
Inf
Die
Vernachlässigung
einer
ganzheitlichen Betrachtungsweise mit
einem mittleren bis langfristigen
Fokus bei der Konzeption ihrer DataWarehouse-Vorhaben führt bei vielen
Organisationen zu Fehlentwicklungen
in ihrer EntscheidungsunterstützungsLandschaft. Diese „Second Best“Lösungen sind oft nur durch einen
verhältnismässig hohen Kosten- und
Zeitaufwand
nachträglich
zu
korrigieren. Vor allem drei Arten von
unzureichenden Herangehensweisen
sind besonders oft zu beobachten:
Informationsverdichtung
2.1 Ganzheitliche Betrachtungsweise
transaktionsorientierte Systeme
Geschäftsprozesse
Horizontale Integration
Abbildung 2: Informationssystemarchitektur einer Unternehmung
Think big: Bei der Planung des
Data-Warehouse-Vorhabens ist
die Informationssystemarchitektur des Unternehmens einzubeziehen (vgl. Abbildung 2). Zur
Unterstützung der Geschäftsprozesse eines Unternehmens existieren etablierte, meist heterogene
betriebliche Informationssysteme.
Zur Unterstützung des täglichen
Geschäftsablaufs kommen transaktionsorientierte Systeme zum
Einsatz. Diese werden durch
Administrations- und Dispositionssysteme unmittelbar gesteuert.
Im
Data-Warehouse-Umfeld
spricht man bei diesen betrieblichen Informationssystemen von
operativen Systemen. Die horizontale Integration der Geschäftsprozesse vieler Unternehmungen ist durch eine Vielzahl
von Projekten unter dem Schlagwort „Business Process Reengineering“ weit fortgeschritten. Das
Data-Warehouse-Konzept kann
in Ergänzung hierzu einen wesentlichen Beitrag zur vertikalen
Integration der Informationen in
einer Unternehmung leisten. Eine
ganzheitliche Konzeption auf der
Grundlage einer zentralen DataWarehouse-Datenbasis ist ein elementarer Bestandteil eines jeden fortschrittlichen analytischen
Informationssystem mit dem Ziel
der Management- bzw. Entscheidungsunterstützung. Abbildung 3
vermittelt einen ersten Eindruck
einer einfachen Data-WarehouseArchitektur. Das Data Warehouse
bildet das Fundament für OLAPTechnologien und „State of the
Art“
Business
IntelligenceFrontends. Die Data-WarehouseArchitektur muss sich zu einem
integralen Bestandteil der gesamten Informationssystemarchitektur entfalten.
•
Start small: Der Aufbau eines
umfassenden Data Warehouse
wird aufgrund von Kosten-, Zeitund Risikoaspekten typischerweise nicht als ein Projekt, sondern
als Sequenz von mehreren (Teil)Projekten gestaltet. Ein langfristiger Horizont ist dabei unabdingbar. Besser (zügig) mit einer
80-prozentigen Lösung beginnen
als nach einer 100-ProzentLösung zu streben, die nie erreicht wird.
Bei der ganzheitlichen Konzeption einer Data-Warehouse-Lösung ist eine
Reihe von zentralen Erfolgsfaktoren
zu berücksichtigen:
•
Zweck: Im Mittelpunkt einer jeden Data-Warehouse-Konzeption
steht der Zweck und die mit diesem verbundenen Ziele. Der idealtypische Zweck eines Data Warehouse ist es, grundsätzlich alle
Auswertungen (auch noch nicht
bekannte) zu ermöglichen. Bei
der Festlegung des Zwecks sollte
beachtet werden, dass ein Data •
Warehouse sicherlich nicht das
Allheilmittel für alle betrieblichen wie organisatorischen Probleme in einem Unternehmen ist.
Vielmehr ist eine realistische Erwartungshaltung gefordert.
•
Data-Warehouse-Prozess: „Data-Warehousing ist kein Produkt,
sondern der Prozess der Zusammenführung und des Managements von Daten aus verschiedenen Quellen mit dem Zweck, eine
einheitliche, detaillierte Sicht auf
einen einzelnen Geschäftsbereich
oder das gesamte Unternehmen
zu erhalten.“ (Gardner, 1998).
Data-Warehouse-Werkzeuge sollten nach dem “Best of Breed”Ansatz entsprechend der spezifischen Anforderungen ausgewählt
werden. Bei einer Unterstützung
durch externe Berater sollte vor
allem auf Herstellerunabhängigkeit und Systemintegrationsfähigkeiten geachtet werden.
•
Unternehmensspezifische, differenzierte Gestaltung: Das
„One Size Fits All“-Konzept erscheint problematisch, da eine
Vielzahl von unternehmensindividuellen Faktoren zu berücksichtigen sind. Dazu gehören u.a. die
historische Informationssystemlandschaft sowie rechtliche oder
ökonomische Rahmenbedingun-
OLAP
Data
Warehouse
o Verbesserung der Informationsqualität zur Entscheidungsunterstützung
o Erhöhung der Effektivität der
Informationsversorgung für
dispositive, entscheidungsunterstützende Aufgaben
o Erhöhung der Wettbewerbsfähigkeit
o Erhalt bestehender bzw. Erwerb neuer Marktanteile
o Schaffung oder Erschließung
neuer Märkte
o Erhöhung
Kundenzufriedenheit
der
o Verbesserung der Produktoder Dienstleistungsqualität
Die Betrachtung einer ganzheitlichen
Konzeption mit einer langfristigen
Perspektive unter Beachtung der genannten Erfolgsfaktoren ist essentiell
für erfolgreiche Data-WarehouseVorhaben.
Da Data-Warehouse-Vorhaben grundsätzlich projektorientiert durchgeführt
werden, wird als nächstes der TheBei der Wirtschaftlichkeitsanaly- menbereich Projektmanagement bese sollten strategische Leistungs- trachtet.
und Nutzenpotentiale als qualitative Faktoren neben quantitativen 2.2 Projektmanagement und
Messgrößen
Berücksichtigung
Vorgehensmodelle
finden. Diese lassen sich auch als
Die mit Data-Warehouse-Vorhaben
verbundenen Aufgaben sind sowohl
im Bezug auf die beanspruchten Ressourcen als auch hinsichtlich der Inhalte umfangreich und komplex und
erfordern ein hohes Maß an Koordinations- und Steuerungsaktivitäten, um
eine termin-, inhalts- und kostengerechte Zielerreichung zu gewährleisten. Somit liegen die besten Voraussetzungen vor, diese Aufgaben in ein
klar definiertes Projekt zu überführen
und strukturiert abzuarbeiten.
Projekte zeichnen sich durch die
Merkmale Neuartigkeit, d.h. es kann
nur bedingt auf vorhandenes unternehmensinternes Know-how oder vorGeschäftsprozesse
liegende Planungen zurückgegriffen
werden, zeitliche Begrenztheit, KomHorizontale Integration
plexität und Beteiligung mehrerer
Argumente für die Rechtferti- Stellen aus. Die Planung, Steuerung
und Kontrolle, das sog. Projektmanagement, begleitet den gesamten EntAbbildung 3: Einfache Data-Warehouse-Architektur
wicklungsprozess, der in ein im VorAdministrations- und Dispositionssysteme
+
transaktionsorientierte Systeme und externe Daten
gen.
gung eines Data-WarehouseProjektes einsetzen:
Informationsverdichtung
Vertikale Integration
Business IntelligenceFrontends
Wirtschaftlichkeitsanalyse: Eine Wirtschaftlichkeitsanalyse bildet die Grundlage zur Beurteilung und Einschätzung der Vorteilhaftigkeit
eines
DataWarehouse-Projektes unter Anwendung geeigneter Methoden
der Investitionsrechnung. Im
Rahmen von Wirtschaftlichkeitsanalysen wird der Versuch unternommen, den Nutzen mit monetären Größen zu bewerten.
Grundsätzlich sollte mit dem
Teilprojekt mit dem größten
messbaren
(quantifizierbaren)
bzw. zumindest identifizierbaren
Nutzen begonnen werden. Typischerweise ist das ein bereichsspezifischer Data Mart mit begrenzter Entwicklungsdauer und
Kosten. Wichtig ist es hierbei die
Gesamtkonzeption, z.B. eines
zentralen Data Warehouse, zu berücksichtigen und schrittweise
parallel weiter auszubauen. Somit
kann eine kurzfristige Realisierung eines Nutzens nachgewiesen
werden, die häufig entscheidend
für eine Genehmigung weiterer
Mittel im Rahmen des gesamten
Data-Warehouse-Vorhabens ist.
aus definiertes, klar abgegrenztes Ergebnis mündet. Dieses kann im DataWarehouse-Kontext
beispielsweise
eine Data-Mart-Entwicklung sein. Der
Projektleiter kann mit weiteren Aufgaben, wie z.B. Entscheiden, Delegieren, Koordinieren und Organisieren
konfrontiert sein. Entscheidend für die
erfolgreiche Durchführung eines Data-Warehouse-Projektes im Kontext
des Projektmanagements sind vor allem zwei Faktoren:
genieurmäßigen“ Vorgehens fest.
Klassische Projektmodelle, wie z.B.
das Wasserfallmodell, weisen bei einer Anwendung im Data-WarehouseKontext eine Vielzahl von Defiziten
auf, da die Entwicklung von Data Warehouses in der Regel von ganz anderen Anforderungen an die Projektdurchführung geprägt ist. Folgende
für Data-Warehouse-Projekte zentrale
Anforderungen sind im Vorgehensmodell besonders zu berücksichtigen:
•
Projektleiter: Erfolgskritisch ist •
die Auswahl eines erfahrenen
und qualifizierten Projektleiters,
der alle Aufgaben im Rahmen des
Projektmanagements konsequent
wahrnehmen kann.
•
Vorgehensmodell: Neben der
Person des Projektleiters ist zu
beachten, dass ein auf DataWarehouse-Vorhaben
abge- •
stimmtes Vorgehensmodel für die
effiziente Unterstützung des Projektmanagements zum Einsatz
kommt.
Um Softwareprojekte besser plan- •
und kontrollierbar zu machen, strebte
man nach einer Strukturierung des
Ablaufs von Softwareprojekten, worunter man die Aufteilung des Projektes in wohldefinierte Teilaktivitäten •
versteht. Diese Vorgehensmodelle legen einen Rahmen für die Softwareentwicklung mit dem Ziel eines „in-
•
Rücksprünge in frühere Phasen
und Schleifen (Iterationen) sind
notwendig.
Die Softwareindustrie hat eine Vielzahl von Vorgehensmodellen hervorgebracht. Jedes Vorgehensmodell hat
besondere Vorzüge, aber auch
Schwachstellen. Beim Data Warehousing bietet sich eine Kombination
von neuartigen Vorgehensweisen an,
um möglichst viele dieser Vorzüge zu
nutzen. Im Folgenden werden vor allem die Merkmale aufgezeigt, die ein
Vorgehensmodell
im
DataWarehouse-Kontext aufweisen sollte.
Zunächst wird jedoch ein dazu passendes exemplarischen Vorgehensmodell (vgl. Abbildung 4) beschrieben.
Der Auftraggeber und die Endbenutzer sind oft nicht in der Lage
ihre Anforderungen an das neue
System in den frühen Projektphasen explizit und/oder vollständig
zu formulieren. Dabei ist das
Motto „I can’t tell you what I
want, but I’ll know it when I see Jedes
Vorgehensmodell/Projektmodell besteht aus dem Durchlaufen
it” häufig anzutreffen.
Laufende Anpassung bzw. Ände- mehrerer Phasen, wobei Phasen ggf.
rung von Anforderungen nach wiederum in Teilphasen oder Aktividem Motto „der Appetit kommt täten weiter untergliedert werden. Am
beim Verzehr“ sind zu berück- Ende ausgewählter Phasen existieren
sog. Phasenlinien bzw. Meilensteine,
sichtigen.
die im Projektverlauf definierte ZwiIm Projekt müssen Projektrisiken schenergebnisse liefern.
frühzeitig erkannt und anschlieDie Kernphasen des Projektes werden
ßend ausgeschaltet oder überdurch vorund nachgelagerte Phasen
wacht werden.
eingeschlossen. In der InitialisieEin linearer, streng sequentieller rungsphase sind grundsätzliche RahProjektablauf ist eine ideale An- menbedingungen, wie z.B. Anwennahme, die in realen Projekten dungszweck,
Data-Warehousemeist nicht erfüllbar ist.
Architektur oder Toolauswahl zu klä-
Initialisierungs-
- Initialisierung
- Bestimmung des
Anwendungszwecks
- Grobe Anforderungsspezifikation
- Analyse der IT-Landschaft
- Def. d. DWH-Architektur
- Erstellen eines Kriterienkatalogs f. DWH-Werkzeuge
- Evaluation u. Empfehlung
d. Werkzeuge
- Konfiguration und
Einrichtung d. ausgew.
Werkzeuge
abschließende
Inkrementelle und iterative Phasen
phase
Phase
Planung nächste Iteration
Schulung der Anwender
Inbetriebnahme
Ziele,
Alternativen
Ziele,
Alternativen
RisikoRisikoanalyse
RisikoRisikoanalyse
Analyse/Design/
Implementierung
...
Analyse/Design/
Implementierung
Analyse, Design und Implementierung
Sicherheits- und Berechtigungskonzept, Metadatenmanagementkonzept
Projektmanagement
Qualitätssicherung und Konfigurationsmanagement
Data-Warehouse-
Gesamtkonzeption
Abbildung 4: Exemplarisches Data-Warehouse-Vorgehensmodell
& Dirty-Realisierung für DataWarehouse-Vorhaben nicht geeignet ist, erlaubt das sog. evolutionäre Prototyping eine Softwareentwicklung, die über eine
Folge von Prototypen im produktiven Programmsystem gipfelt.
ren während sich die abschließende
Phase mit Aktivitäten wie Schulung
oder Inbetriebnahme beschäftigt.
Die Aufgabe der Kernphasen, die sog.
iterativen und inkrementellen Phasen
besteht in der Entwicklung bzw. Integration des Data Warehouse in einzelnen kleinen und überschaubaren
Schritten von ca. 3 bis 6 Monaten
Dauer. Häufig entspricht eine Einheit
einer Data-Mart-Entwicklung. Neben
der Analyse (Informationsbedarfsanalyse, Quelldatenanalyse), dem Design
(Fachkonzeptentwurf, Datenmodellentwurf/-modifikation spielt hierbei
vor allem die Implementierung eine
wichtige Rolle.
Zwei Zitate unterstreichen die hohe
Das Prototyping bringt vor allem Relevanz der Erhebung von Informationen und Wissen im Rahmen der Infolgende Vorteile mit sich:
anschau• Identifikation von weiteren formationsbedarfsanalyse
lich:
fachlichen
Anforderungen
•
Diese Phasen der Softwareentwicklung werden ergänzt durch eine Reihe
von projektbegleitenden Aktivitäten,
wie z.B. Projektmanagement, Qualitätssicherung und Konfigurationsmanagement. Sie finden parallel zum übrigen Projektablauf statt. Eine besonders wichtige projektbegleitende Aktivität ist die Weiterfortführung der
Data-Warehouse-Gesamtkonzeption,
durch die die langfristige Perspektive
des Data-Warehouse-Vorhabens im•
mer im Fokus bleibt.
Das exemplarisch vorgestellte Vorgehensmodell weist folgende Merkmale
auf, die für ein erfolgreiches DataWarehouse-Vorhaben essentiell sind:
•
Iterativ: Die einzelnen Phasen
laufen nicht streng sequentiell ab,
sondern können sich bei Bedarf
auch wiederholen. Die dabei vorgesehene Möglichkeit der Rückkopplung erlaubt auch Abläufe,
die nicht streng „wasserfallartig“
verlaufen, sondern Schleifen enthalten. Im Rahmen der Rückkopplung sollte die bisherige
Sammlung der Anforderungen
ggf. modifiziert werden kann.
•
Inkrementell: Die Entwicklung
erfolgt in kleinen überschaubaren
Einheiten. Die Inkremente werden normalerweise im Rahmen
der jeweiligen Iteration erstellt.
•
Prototyping: Die Entwicklung
von Prototypen trägt zur besseren
Kommunikation der fachlichen
Anforderungen mit dem Auftraggeber bei. Es werden unterschiedliche Arten von Prototypen unterschieden. Während der Wegwerfprototyp im Rahmen einer Quick
für die darauf aufbauenden Designund Implementierungsschritte. Dem
hohen Stellenwert der Informationsbedarfsanalyse wird dadurch Rechnung getragen, dass sie hier noch
einmal explizit hervorgehoben wird.
•
nach
dem
WYSIWIGPrinzip (what you see is what
you get).
“Knowledge is the only meaningful
economic resource” (Drucker,
1995)
Risikominimierung bezüglich der fachlichen Anforderungen.
“In an economy where the only
certainty is uncertainty, the one
sure source of lasting competitive
advantage is knowledge” (Nonaka,
1991)
Verbesserung der Anforderungsanalyse und -definition
hinsichtlich ihrer Konsistenz Mit der Informationsbedarfsanalyse
und ihrer Detaillierungstiefe. werden die Informationsbedürfnisse
des Managements und der jeweiligen
• Da man in kürzeren Abstän- Fachbereiche ermittelt.
den fertige Teilergebnisse
mit dem Auftraggeber ab- Spätere Phasen in der Entwicklung
stimmen kann, erhöht sich des Data-Warehouse-Systems bauen
im Allgemeinen auch die auf den Ergebnissen der Informationsbedarfsanalyse auf. Somit sind
Akzeptanz des Systems.
Fehler und Unzulänglichkeiten in darRisikogesteuert: Es bietet sich auf folgenden Entwicklungsphasen
an, eine Risikoanalyse vorzu- nur mit großem Aufwand korrigierschalten (Auflösung der aktuell bar.
sichtbaren Projektrisiken).
Bevor der Begriff Informationsbedarf
Data Warehousing ist kein einmaliges eingehend betrachtet und darauf aufVorhaben mit klar definiertem Ab- bauend ein Lösungsansatz vermittelt
schluss. Sowohl die Informationsbe- wird, werden im Folgenden eine Reidürfnisse der Endbenutzer wie auch he von Problemen, die bei der Erhedie operativen Applikationen als Da- bung des Informationsbedarf auftreten
tenquellen sind vielen Änderungen können, skizziert:
unterworfen, die sich permanent auf
ein Data Warehouse auswirken. Viel- • Die Phantasie der zukünftigen
Anwender reicht in der Praxis in
mehr führen diese zu weiteren kleineder Regel nicht aus, den wirkliren Teilprojekten. Deshalb sind die
chen Informationsbedarf zu Begenannten Merkmale besonders wichginn eines Projekts überhaupt und
tig.
abschließend zu definieren. Dies
liegt teilweise daran, dass der
2.3 InformationsbedarfsanaFachbereich bzw. das Management seinen jeweiligen Informalyse
tionsbedarf selbst nicht gut genug
Der Aktivität Informationsbedarfsanakennt.
lyse ist im Rahmen von DataWarehouse-Vorhaben ein sehr hoher • Der Informationsbedarf ist in vielen Fällen nur vage bestimmbar
Stellenwert beizumessen, da der Geund hängt vor allem von der
winnung von Informationen und Wiszugrunde liegenden Aufgabensen als Grundlage für die Entscheistellung, den angestrebten Zielen
dungsfindung eine zentrale Bedeutung
und den psychologischen Eigenzukommt.
schaften der Entscheidungsträger
Innerhalb eines Vorgehensmodells
ab.
(vgl. Abbildung 4) ist sie der Analyse
zuzuordnen und somit das Fundament
•
•
Zudem sind sich die Anwender
oft nicht bewusst, welche neuartigen Informationen mit dem zu
entwickelnden Data-WarehouseSystem bereitgestellt werden •
können.
Häufig sind falsche Erwartungen
des Managements bzw. der Endanwender im Hinblick auf den
gewünschten Informationsbedarf •
anzutreffen. Dies kann ein weitreichendes Projektrisiko sein.
Abbildung 5 zeigt den Zusammenhang zwischen den wesentlichen Begrifflichkeiten bei der Informationsbedarfsanalyse. Das Verständnis von
Informationsangebot, -nachfrage, subjektiven vs. objektiven Informationsbedarf erlaubt es, die genannten Prob- •
leme besser einzuordnen:
•
Informationsraum: Die den ein-
onsbedarf beinhaltet jene Infor- •
mationen, die für den Entscheidungsträger zur Erfüllung seiner
Aufgaben relevant sind.
Subjektiver
Informationsbedarf: Der subjektive Informationsbedarf umfasst jene Informationen, die dem Entscheidungsträger als relevant erscheinen.
Informationsnachfrage: In der
Regel artikulieren Entscheidungsträger nur einen Teil ihres subjektiven Informationsbedarfs. Deshalb wird die Informationsnachfrage, d.h. die konkret nachgefragte Informationsmenge, als
Teilmenge des subjektiven Informationsbedarfs beschrieben.
Informationsstand: Der Teil der
Informationsversorgung,
der
durch den objektiven Informationsbedarf geprägt ist, ist der Informationsstand. Der Informationsstand ist die für die Aufgabe
des Entscheiders relevante Informationsmenge, die letztendlich
für eine Entscheidung sinnvoll
verwertet werden kann.
Ein Königsweg für die Informationsbedarfsanalyse gibt es nicht. Beispielsweise können Eigenschaften der
Vorgehensmodelle, wie Prototyping
sowie inkrementelle und iterative
Phasen helfen, da die späteren Anwender unmittelbar und frühzeitig
eingebunden werden. Entscheidend ist
eine umfassende Interaktion mit dem
Informationsangebot: Das In- betroffenen Personenkreis (Fachleuformationsangebot wird definiert ten bzw. Entscheidern). Das System
als die Gesamtheit der Informati- soll Teil der Tagesarbeit dieser Mitarbeiter werden, von diesen akzeptiert
und ständig genutzt werden. Wichtig
ist die Kommunikation, d.h. zum Beispiel sind die Mitarbeiter des
Unternehmens frühzeitig über das
Projekt, dessen Intention, Inhalt und
interne Organisation zu informieren.
Damit die Anwenderwünsche erkannt
und erfasst werden können, werden
im Folgenden mehrere Teilschritte als
Lösungsansatz für die Informationsbedarfsanalyse vorgestellt:
•
Abbildung 5: Informationsangebot, -nachfrage u. -bedarf
zelnen Begriffen jeweils zugeordneten
Informationsmengen
sind Bestandteil eines umfassenden Informationsraums und werden hier anschaulich durch unter- •
schiedlich große sich teilweise
überlappende Kreise symbolisiert.
•
Objektiver
Informationsbedarf: Der objektive Informati-
onen, die einem Nachfrager zu
einem bestimmten Zeitpunkt an
einem bestimmten Ort zur Verfügung stehen.
Informationsversorgung: Die
Schnittmenge zwischen Nachfrage und Informationsangebot wird
als Informationsversorgung bezeichnet.
Identifikation von Informationsbedarfen: Data Warehousing
soll durch die Mitarbeiter „gelebt“ und als dynamischer Prozess verstanden werden. Dafür ist
es jedoch zwingend erforderlich,
die Mitarbeiter mit den Methoden
der Informationsbedarfsanalyse
vertraut zu machen, um die erforderlichen Ergebnisse zu erzielen.
Viele Methoden der Informationsbedarfsanalyse aus der klassischen Softwareentwicklung lassen sich problemlos im DataWarehouse-Umfeld anwenden:
(1) Deduktive Methoden: Zu
den deduktiven Methoden zählen
vor allem die Modellanalyse, die
Analyse relevanter Gesetzestexte
oder von Literaturquellen, die
Anwendung von Kreativitätstechniken, wie z.B. Brainstorming sowie die Aufgabenanalyse.
(2) Induktive Methoden: Induktive Methoden sind z.B. die Dokumentenanalyse,
datentechni-
sche Analysen, Organisationsanalyse sowie Befragungen durch Interviews oder Fragebögen.
Diese Methoden sollten als •
Grundlage für die Strukturierung
von Anwenderwünschen eingesetzt werden. Wichtig ist eine
im Hinblick auf eine spätere In- Projektteams sind besonders folgende
tegration in die Data-Warehouse- Problembereiche zu beachten:
Umgebung zu bewerten.
• Rollen der Mitarbeiter bei der
Zusammensetzung des ProjektPriorisierung zusätzlicher Informationsbedarfe: Die durch
teams
das Data-Warehouse-System be- • Auswahl des Projektteams
reitzustellenden
Informationen
• Einbettung der Projektorganisation in die Unternehmensorganisation
•
Identifikation von Informationsbedarfen
Abbildung 6: Methoden der Informationsbedarfsanalyse
standardisierte, flächendeckende
Erhebung, sowie eine systematische Auswertung.
Im Data-Warehouse-Umfeld bietet sich vor allem eine Kombination induktiver und deduktiver
Elemente an (vgl. Abbildung 6).
•
•
Synchronisation von Informationsbedarf und -angebot: Der
ermittelte Informationsbedarf ist
mit dem vorhandenen Informationsangebot abzustimmen. Dies
erfolgt in den meisten Fällen über
eine Quelldatenanalyse, in der die
Wünsche der Anwender mit den
Daten in den operativen Systemen abgeglichen werden. Ein
großer Teil der Bedürfnisse nach
strategischen Managementinformationen kann jedoch häufig
nicht unmittelbar befriedigt werden, da die notwendigen Daten
nicht vorhanden sind. Hier gilt es
abzuschätzen, ob eine Integration
externer Datenquellen den zu erwartenden Nutzen rechtfertigt.
Allenfalls gilt es die Erwartungen
bzw. die Informationsbedürfnisse
zu korrigieren.
Bewertung von Informationslücken: Es ist ein Vergleich des IstZustands der Informationsversorgung mit einem möglichen zukünftigen Soll-Zustand der Informationsversorgung durchzuführen. Informationslücken sind
Rollen: Die mit der Entwicklung eines Data Warehouse verbundene
Komplexität erfordert das Einbinden
einer Vielzahl spezialisierter Fähigkeiten. Diese Fähigkeiten lassen sich
wiederum zu Rollen zusammenfassen.
Neben Rollen, die im Rahmen der
klassischen
Softwareentwicklung
weitgehend bekannt sind, sind im Data-Warehouse-Umfeld auch neuartige
Rollen, wie z.B. die des ETL- oder
OLAP-Spezialist zu besetzen. Im Folgenden wird eine mögliche Spannbreite der benötigter Rollen aufgezeigt, die im Projekt als Checkliste
herangezogen werden kann.
müssen aufgrund von beispielsweise zeitlichen oder finanziellen
Restriktionen und ihrer Wichtigkeit für die betriebliche Aufgabenerfüllung beurteilt und priorisiert werden. Dies kann in •
Workshops erfolgen, in denen eine Rückkopplung zum späteren
Endanwender stattfindet.
Als Ergebnis der Informationsbedarfsanalyse sollte zumindest ein
konzeptuelles, semantisches Datenmodell, das die Anwenderwünsche erfasst, eine Menge möglicher Abfragen/Berichte sowie eine Auswahl der
hierzu notwendigen Datenquellen.
Es ist grundsätzlich illusorisch zu
glauben, dass die Anforderungen der
Nutzer vollständig erfasst werden
können. Eine laufende Abstimmung
mit allen Beteiligten fördert die Akzeptanz und hilft die Anforderungen
ggf. anzupassen bzw. zu erweitern.
Sponsoring durch das Management
•
2.4 Projektteam
Neben eher formalen Faktoren, wie
Vorgehensmodell,
Informationsbedarfsanalyse und Konzeption spielt im
Projektalltag der menschliche Faktor
•
eine nicht zu unterschätzende Rolle.
Vor allem das Projektteam und seine
Einbettung in das betriebliche Umfeld
bestimmen maßgeblich den Erfolg eines Data-Warehouse-Vorhabens. Bei
der Gestaltung eines schlagkräftigen
Projektleiter/Teamleiter: Dies
ist die zentrale Schlüsselrolle für
das Projekt. Der Projektleiter ist
einerseits für Projektplanung, steuerung und -kontrolle und andererseits für die Kommunikation
und das Projektmarketing im
Sinne einer gezielt durchgeführten Werbekampagne für das Vorhaben zuständig. Dies setzt neben
Führungsqualitäten ein weitreichendes Verständnis der betrieblichen Zusammenhänge voraus.
Der Projektleiter sollte eine starke Persönlichkeit sein, die eine
straffe Planung und eine konsequente Anpassung an Abweichungen vornimmt.
Data-Warehouse-Architekt:
Die zentrale Aufgabe des DataWarehouse-Architekts ist die
Konzeption einer ganzheitlichen
Data-Warehouse-Architektur losgelöst von den operativen Systemen.
Datenbank-Administrator: Umfassende Kenntnisse der zugrunde
liegenden Datenbank sind für ein
Data-Warehouse-Vorhaben genauso essentiell wie bei der klassischen
Softwareentwicklung.
Neue Schwerpunkte sind dabei
z.B. Aggregationsbildung und die
Beachtung von Zeitfenstern beim
Datenladen.
•
•
Spezialist für Datenmigration/ETL-Spezialist: Die Extraktion, die Datentransformation und
das Datenladen unter Beachtung
der Datenqualität und unter Performanzgesichtspunkten stellt eine wesentliche Aufgabe dar.
Spezialist für Altanwendungen
(Legacy Data): Da die für das
Data Warehouse bestimmten Daten oftmals aus einer Vielzahl
von heterogenen Altanwendungen extrahiert werden, sind fundierte Kenntnisse dieser Systeme
entscheidend.
und den Fachabteilungen gefunden werden. Die Einbindung der
Fachbereiche in die Entwicklungsteams ist hier von besonderer Bedeutung, da nur auf diese
Weise zu gewährleisten ist, dass
das Data Warehouse später auch
den Anforderungen der Benutzer
entspricht. Hierbei sind die verschiedenen späteren Nutzertypen,
wie z.B. Power User und Standard User, zu berücksichtigen.
Die Zusammenarbeit mit den
Fachanwendern bringt verstärkt
fachliche Kompetenz in das Projekt ein. Diese Personen können
im Rahmen der Einführung zur
Information der übrigen Anwender bzw. als Multiplikatoren
eingesetzt werden.
•
Spezialist für Qualitätssiche- •
rung: Im Rahmen des DataWarehouse-Vorhabens ist ebenfalls für eine qualitätsgesicherte
Entwicklung Sorge zu tragen.
•
Tester: Alle Entwicklungsschritte sind vor Überführung in den
Wirkbetrieb analog zur klassischen Softwareentwickung intensiv zu testen.
• Sponsor: Der „Schirmherr“, der
das Data-Warehouse-Vorhaben
Data-Mart-Entwickler/OLAPüberwacht. Auf diese Rolle wird
Spezialist: Neben der Dataspäter im Abschnitt noch detailWarehouse-Datenbasis sind vor
lierter eingegangen.
allem bereichs- bzw. abteilungsspezifische Sichten, die sog. Data Eine konkrete Projektsituation kann
Marts, von besonderer Bedeu- die Zuordnung einer Rolle zu mehretung. Die diesen zugrunde lie- ren Mitarbeiter genauso wie eine
gende Verarbeitungsform wird Zuordnung mehrerer Rollen zu einem
als Online Analytical Processing Mitarbeiter erfordern. Bei der Beset(OLAP) bezeichnet. Sie bilden zung des Data-Warehouse-Teams
die Basis für das neu zu gestal- sollte vor allem auch auf eine angetende Data-Warehouse-Berichts- messene Teamgröße und eine Mitarwesen.
beiterkonstanz im Projektverlauf
besonderes
Augenmerk
gelegt
Infrastrukturspeziawerden.
Häufig
ist
es
sinnvoll
ein
sog.
list/Systemadministrator:
Da
Kernprojektteam
zu
bilden,
das
Data-Warehouse-Projekte immer
abhängig
vom
Projektverlauf
durch
in die bestehende Landschaft des
Unternehmens zu integrieren Teilprojektteams jeweils ergänzt wird.
sind, ist die Rolle eines Infra- Teamauswahl: Bei der Zusammenstrukturspezialisten wichtig. Die- stellung des Projektteams können
ser wird ergänzt durch System- Engpässe offensichtlich werden:
administratoren für die bestehen• Ist genügend Personal für die erden Systeme sowie für das neu zu
forderliche Aufgabe vorhanden?
konzipierende Data-Warehouse• Sind die benötigten Fähigkeiten
System.
innerhalb der Organisation verPower User und Standard Ufügbar?
ser: Für den gesamten DataWarehouse-Entwicklungsprozess Data Warehousing stellt spezifische
muss eine geeignete Kooperati- Anforderungen an die einzusetzende
onsform zwischen IT-Abteilung Methodik und Systematik. Das dafür
•
•
•
benötigte Wissen ist in den Unternehmen in aller Regel nicht oder nicht
ausreichend vorhanden. Häufig besitzt
das erste Data-Warehouse-Vorhaben
in einer Unternehmung eine Pionierfunktion.
Dies führt zunächst zu einer Makeoder Buy-Entscheidung. Diese beiden
Extrempole, die vollständige Eigenrealisierung bzw. das komplette Outsourcing der Entwicklung kommen in
den seltensten Fällen in ihrer Reinform zur Anwendung. Dazwischen
existiert eine Vielzahl von sinnvollen
Möglichkeiten, die abhängig von den
unternehmerischen Rahmenbedingungen gestaltet werden sollte.
Objektivität, Wissenstransfer und
Ausnutzung des vorhandenen Erfahrungsschatzes sind oft die zentralen
Gründe, sich externe Unterstützung in
Form von Beratungsleistungen zuzukaufen. Folgende Formen der externen Unterstützung finden in den meisten Fällen Anwendung:
Verantwortlicher für Public
Relations: Er vermittelt den Nutzen des Data Warehouse und
„verkauft“ das Projekt nach „oben“. Insbesondere bei großen
Data-Warehouse-Vorhaben wird
hierfür eine eigenständige Rolle •
losgelöst von den Aufgaben des
Projektleiters benötigt.
Coaching Modell: Der Berater
stellt sein methodisches und fachliches Wissen im Rahmen der
einzelnen Arbeitsschritte zur Verfügung und führt durch die Einzelphasen ohne an der inhaltlichen Erarbeitung der Informationen unmittelbar beteiligt zu sein.
•
Begleitende Funktion: Der Berater erhebt gemeinsam mit den
Mitarbeitern des Unternehmens
die benötigten Informationen und
wirkt aktiv in den Teilschritten
mit.
•
Wissenserweiterung: Schulung,
Seminare, Vorträge bieten weitere Möglichkeiten, fehlendes
Know-How aufzubauen.
Bei der Auswahl und Einbindung externer Berater sollte vor allem auf folgende Faktoren geachtet werden:
•
Die externen Berater sind in das
Projektteam geeignet zu integrieren, damit sie nicht als Eindringlinge wahrgenommen werden.
•
Bei der Auswahl der Berater sollte insbesondere auf ausreichende
Erfahrung im Aufbau und der Integration von Data-WarehouseSystemen geachtet werden. Dies
lässt sich häufig durch entsprechende Referenzprojekte in der
jeweiligen Branche überprüfen.
•
mehreren Merkmalen vorgeschlagen,
die eine weitreichende Analyse des
vorliegenden Datenbestands ermöglichen. Während die innere Datenqualität die Qualität der Daten an sich zu
bewerten hilft, stellt die kontextabhängige Datenqualität die Daten in
einen Interpretationszusammenhang.
Die Betrachtung der Darstellungsqualität und die Qualität des Zugangs
Folgende Aussagen belegen die Be- runden die beiden anderen ab.
deutung einer angemessenen Daten- Um die vorgestellten Dimensionen
besser verstehen zu können, ist es
qualität anschaulich:
nützlich, die Ausprägungen zu ken“A smaller warehouse with cleaner data
nen, anhand derer die Dimensionen
can be better than a large warehouse with
beurteilt werden können:
bad data.”
Externe Berater sollten möglichst Data Warehouse in Frage. Nach dem
frühzeitig in das Projekt einge- Leitspruch „Garbage in, garbage out”
stoßen mangelhafte Daten auf Akzepbunden werden.
Projektorganisation: Obwohl das tanzprobleme beim EntscheidungsträData Warehouse längerfristig zu ei- ger. Dessen einmal erworbenes genem permanenten Bestandteil der täg- sundes Misstrauen gegenüber der belichen Arbeit der Betroffenen wird, ist reitgestellten Datengrundlage verureine Integration der Projektarbeit in teilt so manches Data-Warehousedas operative Tagesgeschäft in der Projekt nachhaltig zum Scheitern, da
Regel zum Scheitern verurteilt. Der niemand die enthaltenen Daten nutzt.
„Vorrang des Tagesgeschäfts“ stempelt das Data-Warehouse-Projekt zu
einer unwichtigen Nebentätigkeit ab.
Daher sollte eine eigenständige Projektorganisation etabliert werden, wobei deren Mitglieder von der klassischen Linienorganisation während der
Projektlaufzeit weitgehend abgetrennt
werden müssen. Ob hierbei eine permanente oder eine temporäre Projektorganisation gewählt wird, ist nicht
entscheidend. Wichtig ist es jedoch,
die Mitglieder dieser Projektorganisation funktions- bzw. bereichsübergreifend zu besetzen, um möglichst viele
Facetten ausleuchten zu können.
Sponsoring: Jedes Data-WarehouseProjekt ist Chefsache und sollte von
einer einflussreichen Persönlichkeit
aus einer höheren Managementebene
begleitet werden. Dieser Mentor, häufig aus der Unternehmensleitung, ist
verantwortlich für das Vorhandensein
des Data-Warehouse-Projektes, ermöglicht den initialen Startschuss und
fördert das Projekt während der Laufzeit. Idealerweise ist das Commitment
aller verantwortlichen Führungskräfte
zu sichern und auf eine hierarchieübergreifende
Projektunterstützung
vom Top Management bis zu den jeweiligen Process Ownern hinzuarbeiten. Ohne zumindest einen mächtigen
Mentor wird das Projekt bei den ersten auftretenden Problemen häufig bereits in Frage gestellt. Da bei einer
ganzheitlichen
Data-WarehouseKonzeption in den meisten Fällen Personen aus den unterschiedlichsten
Unternehmensbereichen mit häufig
unterschiedlichsten „subjektiven Mikrointeressen“ beteiligt sind, ist eine
einflussreiche „Entscheidungsinstanz
bzw. Mentor“ zwingend erforderlich.
„Nothing is more likely to undermine the
performance and business value of a data
warehouse than inappropriate, misunderstood, or ignored data quality.“
•
Werden Probleme der Datenqualität
zu Beginn eines Projektes als trivial
betrachtet oder schlicht ignoriert, so
rächt sich dies im weiteren Projektverlauf.
•
Um eine besseres Verständnis für die
Probleme und Auswirkungen unzureichender Datenqualität zu vermitteln,
werden zwei Definitionen vorgestellt, •
die die wesentlichen Facetten
ausleuchten:
•
•
Nach der Norm DIN ISO 8402 ist
Qualität durch die „Gesamtheit
von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte
und vorausgesetzte Erfordernisse
zu erfüllen“ definiert. Diese eher
technische Festlegung stellt die
Übereinstimmung der Eigenschaften der „Daten“ mit vorher
festgelegten Anforderungen in
den Vordergrund.
•
Innere Datenqualität: Genauigkeit, Objektivität, Glaubwürdigkeit, Vertrauenswürdigkeit. Diese
Ausprägungen manifestieren sich
häufig in inkorrekten Werten,
syntaktischen Fehlern, Schlüsselanomalien und dem Auftreten
von Duplikaten.
Kontextabhängige Datenqualität: Unvollständigkeit, Nichtrelevanz, Nichtaktualität (zeitlicher
Bezug) und Anwendungsbezug.
Darstellungsqualität: ungenügende Dateninterpretationen, wie
z.B. nicht interpretierbare Schlüsselsysteme oder frei verwendete
Textfelder, Widerspruchsfreiheit,
knappe Darstellung, Verständlichkeit.
Zugangsqualität: Schutzverletzungen, fehlende Zugriffsmöglichkeiten.
Bei der Analyse der Datenqualität
anhand der vorgestellten Qualitätsdimensionen zeigt sich, dass vor allem
folgende drei Problemfelder entFür L. English sind aber vor al- scheidend
für
Data-Warehouselem die Anforderungen der End- Systeme sind:
anwender entscheidend. Deshalb
• Nicht korrekte Daten: 1-5% aller
versteht er unter Datenqualität:
Datenfelder sind fehlerbehaftet.
„Consistently meeting all knowledge worker and end-customer • Inkonsistenzen zwischen Daten in
unterschiedlichen Datenbanken.
expectations“.
Diese anwenderbezogene Sichtweise
im Sinne von „fitness for purpose“
bzw. „fitness for use“ zeigt, dass die
Datenqualitätsanforderungen grundsätzlich immer abhängig vom jeweiligen Kontext festzulegen sind.
•
Nicht verfügbare Daten sind notwendig für Entscheidungen.
Diese Datenqualitätsprobleme führen
neben unmittelbaren Auswirkungen
auf der operativen Ebene auch zu mit2.5 Datenqualität
telbaren Auswirkungen auf der Ebene
der
Entscheidungsunterstützung
Die
Beurteilung
der
Datenqualität
Eine unzureichende Qualität der Daten stellt häufig alle noch so intensi- kann anhand von Dimensionen vor- (dispositive Ebene).
ven Bemühungen zum Aufbau eines genommen werden. Huang et al. 1999
haben vier Kategorien mit jeweils
Bezogen auf die operative Ebene sind
dies vor allem folgende Auswirkungen:
•
•
Unkorrekte Daten führen zur •
Verärgerung der betroffenen
Kunden und damit zu einer geringeren
Kundenzufriedenheit.
Auch die Mitarbeiter des
Unternehmens verspüren durch
die damit verbundenen Konflikte •
häufig eine geringere Arbeitszufriedenheit.
Die Kosten für schlechte Datenqualität sind für Unternehmen
sehr hoch. Nach Schätzungen liegen sie bei 8 bis 12 % des Umsatzes. Diese Kosten entstehen,
weil falsche und fehlende Daten
zu einem Mehraufwand führen,
der ansonsten vermieden werden
könnte. Die Korrektur qualitativ
unzureichender Daten ist im Vergleich zu qualitätssichernden
Maßnahmen bei der Datenerfassung um den Faktor 5 bis 10 teurer.
Die aufgezeigten Folgen werden auf
der dispositiven Ebene durch weitere
Auswirkungen verstärkt:
•
Daten bilden die Basis für Analysen und Auswertungen eines jeden Data-Warehouse. Qualitativ
hochwertige und somit geeignete
Auswertungen sind nur auf
Grundlage korrekter und den Anforderungen entsprechender Daten zu erreichen. Eine unzureichende Datenqualität führt zu
Das
Falschbeurteilungen und in letzter
Konsequenz auch zu schlechteren
Entscheidungen.
zations have to distinguish between what is vital and what is
merely desirable.”
Diese Wirkung wird verstärkt •
durch massive Akzeptanzprobleme bei den Entscheidungsträgern,
die sich im fehlenden oder unzureichenden Vertrauen in die Daten widerspiegeln.
Datenqualitätsbestimmung: Es ist
zunächst ein Bewusstsein über
den aktuellen Stand der Datenqualität im Unternehmen zu
schaffen. “This understanding is
mandatory in data warehousing
environments characterized by
multiple users with different
needs for data quality.”
Wird die Korrektur der Daten
nicht bereits weitgehend auf der
Ebene der operativen Systeme
vorgenommen, führt dies zu er- •
heblichen Kosten für das nachträgliche Bereinigen der Daten
beim Laden in die DataWarehouse-Landschaft.
Der Zusammenhang zwischen Zeit,
Kosten und Qualität lässt sich darüber
hinaus anschaulich im sog. „Teufelsdreieck“ oder auch „magischen Dreieck“
veranschaulichen
(vgl.
Abbildung 7). Das Dilemma besteht
darin, dass eine Verbesserung des
Qualitätsaspekts zu einer Erhöhung
der Kosten und Zeitaufwände und
umgekehrt führt. Umso wichtiger ist
es, sich bereits frühzeitig im DataWarehouse-Prozess mit möglichen
Problemen der Datenqualität auseinanderzusetzen.
English (English, 1999) schlägt folgende Schritte vor, um sich Problemen in der Datenqualität zu nähern:
•
•
Auf Basis eines Soll-/IstAbgleichs mit den Ergebnissen
der beiden ersten Schritte ist eine
Kostenbewertung für nicht qualitativ geeignete Daten aufzustellen.
Auf einer auf Schritt drei aufzusetzenden Priorisierung ist eine
Datenbereinigung und Datenumstrukturierung anzustoßen.
Für die Sicherung der Datenqualität
lässt sich eine Vielzahl von Maßnahmen, Konzepten, Abläufen und Methoden heranziehen. Im DataWarehouse-Umfeld ist als Schwerpunkt die Auswahl geeigneter Werkzeuge für den ETL-Prozess zu berücksichtigen. Nicht zuletzt wegen der
komplexen Bereinigungsprozesse gehen Schätzungen davon aus, dass der
Aufwand für den ETL-Prozess bis 80
Prozent
der
gesamten
DataWarehouse-Projektdauer
betragen
kann.
Definition und Festlegung von
Datenqualitätsanforderungen aus
Nutzersicht für die Entschei- Viele der am Markt verfügbaren ETLdungsunterstützung. ,,... organi- Werkzeuge besitzen bereits umfangreiche Möglichkeiten zur Bereinigung
der Datenqualität. Darüber hinaus hamagische Dreieck
ben sich spezialisierte Werkzeuge für
m a x im a l
den Bereinigungsprozess etabliert.
Die folgenden Kategorien zeigen die
Q u a lit ä t
mögliche Bandbreite von Unterstützungsmöglichkeiten auf:
•
Data Migration Tools: Diese
Werkzeuge unterstützen die Extraktion, den Transport und die
Transformation von Daten auf ihrem Weg in das Data-Warehouse.
Vor allem die Transformationsregeln, Filtereinstellungen, Vorgaben für Wertebereiche in der
Transformationsphase verbessern
Plausibilitäts- und Konsistenzprüfungen
•
Data Scrubbing/Profiling Software: Diese Werkzeuge analysieren und lesen die Daten ein. Sie
Z e it
K o s te n
m in im a l
m in im a l
Abbildung 7: Das magische Dreieck
entdecken Zusammenhänge auf
Basis von Regeln, neuronalen
Netzen oder durch Fuzzy Logik.
konsistenzen
des
Data- meist eine Veränderung in den Daten,
Warehouse-Prozesses im Vorder- Strukturen und Prozessen der DataWarehouse-Umgebung.
grund.
Data Auditing/Profiling Tools: • Nutzen aus Entwicklersicht:
Aus Entwicklersicht sollen mit
Diese Werkzeuge entdecken die
Metadaten die Zusammenhänge
Datenregeln durch die Datenanades Administrationsprozesses aulyse selbst. Sie stellen darüber
hinaus Analysen auf Basis statistomatisiert werden.
tischer Stichproben zur Verfü- Generell gilt es anzumerken, dass die
gung.
Menge aller Daten, die man unter dem
Das Aufdecken von Fehlern und Un- Begriff Metadaten kategorisiert, sehr
gereimtheiten in den geladenen Daten vielschichtig und umfangreich sein
führt häufig auch zum Aufspüren von kann. Metadaten werden als Daten
Mängeln in der operativen Vorsyste- über Daten definiert. Sie beschreiben
men. Diese Mängel sollten, wenn den inhaltlichen und strukturellen
möglich, immer auch am Ort ihrer Aufbau und die Bedeutung von Daten. „Metadata is like the roadmap to
Entstehung beseitigt werden.
Nach einem weiter gefassten Be- data.” Genauso wie ein Katalog einer
griffsverständnis lässt sich auch der Bibliothek sowohl den Inhalt als auch
Total Quality Management (TQM)- den Bücherstandort beschreibt, ebenGedanke aus der Produktion auf As- so zeigen Metadaten auf den Ort und
pekte der Datenqualität übertragen. In die Bedeutung der verschiedensten Inin
einer
Datadiesem Zusammenhang kann von ei- formationen
Warehouse-Umgebung.
„Metadata
nem Total Data Quality Management
(TDQM) gesprochen werden. Dieser can be described as a description of
rundet die vorgestellten Aspekte der what you wish were in your data
Datenqualität durch eine Übertragung fields.“
•
der Sicherstellung der Datenqualität
in allen Data-Warehouse-Phasen –
von der Planung über die Implementierung bis zur Wartung – ab.
2.6 Metadatenmanagement
In nahezu allen Bereichen einer DataWarehouse-Architektur entstehen Metadaten bzw. werden Metadaten benötigt. Durch Metadaten soll die Komplexität des Data Warehouse beherrschbar gemacht werden. Folgende
Aussage belegt die hohe Relevanz
von Metadaten anschaulich:
„Metadata is the data warehouse’s
Gordian knot, and Alexander and his
sword are nowhere in sight.“
(Kimball et al. 1998)
Der Nutzen von Metadaten im DataWarehouse-Umfeld ist vielfältig:
•
Allgemeiner Nutzen: Metadaten
sollen ein Verständnis der Zusammenhänge im Data Warehouse für Anwender wie auch Entwickler vermitteln.
•
Nutzen aus Anwendersicht: Aus
Anwendersicht steht der Aufbau
eines einheitlichen Begriffs- und
Definitionssystems, die Transparenz und Nachvollziehbarkeit
sowie die Vermeidung von In-
Die Metadatenhaltung in heutigen Data-Warehouse-Umgebungen ist durch
eine Vielzahl von Problembereichen
gekennzeichnet, deren Verständnis für
die darauf aufbauenden Lösungsansätze essentiell sind:
•
Analog zu den Problemen der
Datenintegration existieren vergleichbare Probleme bei der Metadatenintegration. Beim Aufbau
eines umfassenden Metadatensystems sind Vagheiten, Synonyme,
Homonyme anzutreffen, die den
Entwicklungsprozess behindern.
•
Im Rahmen des Data-Warehouse
Prozesses sind häufig viele spezialisierte Werkzeuge mit separater
Metadatenhaltung, die als Standardsoftware angeboten werden
nach dem Best of Breed-Ansatz
zu integrieren.
•
Die Verwendung von verschiedenen produktspezifischen, proprietären Speicherungsformaten oder
der Einsatz proprietärer Application Programming Interfaces (APIs) bei der Metadatenhaltung erschwert die Integration.
•
Weiterhin stellen die große Anzahl von Komponenten, aus denen ein Data-Warehouse bestehen
kann, und die Tatsache, dass diese Komponenten u.U. von unterschiedlichen Herstellern stammen, hohe Anforderungen an die
Metadateninteroperabilität.
Folgende zwei Beispiele veranschaulichen den Zusammenhang zwischen
Daten und Metadaten:
Daten:
26.10.01
IC 253
Metadaten:
Datum im Format
TT.MM.JJ
Zugnummer oder
Elektrisches Bauteil
Metadaten lassen sich grundsätzlich
in fachliche und technische Metadaten
differenzieren. Während technische
Metadaten der Entwicklung und dem
Betrieb des Data Warehouse, und damit den Entwicklern zugeordnet werden, unterstützen die fachlichen Metadaten die Nutzung des Data Warehouse durch die Endanwender.
Ein umfassendes zentrales Metadatenmanagement in einem Data Warehouse ist heutzutage noch nicht durch
ein entsprechendes Werkzeug vollständig abgedeckt. Vielmehr ist ein
Darüber hinaus lässt sich eine aktive dezentraler Ansatz vorherrschend, der
und passive Metadatenhaltung unter- die Berücksichtigung folgender Probscheiden. Eine passive Metadatenhal- lembereiche mit sich bringt:
tung dient ausschließlich der Beschreibung der Daten (Dokumentati- • Die Gewährleistung des Austausches zwischen den verschiedeon), Strukturen und Prozesse einer
nen Herstellerwelten bzw. die InData-Warehouse-Umgebung. Als aktegration in ein einheitliches Motiv wird eine Metadatenhaltung bedell ist zu beachten.
zeichnet, die es nicht nur erlaubt Beschreibungen zu speichern, zu verän- • Zudem sind begleitende organisadern und auszugeben, sondern darüber
torische Maßnahmen aufzusetzen,
hinaus aus den gespeicherten Metadadie eine kontinuierliche Pflege
ten Aktionen in Form einer Steuerung
der Metadaten fördern.
des Data-Warehouse-Prozesses abzu- Um eine integrative Sichtweise auf
leiten. Aktive Metadaten bewirken die Metadaten zu fördern, sollten die
ausgewählten Werkzeuge einem einheitlichen „Metadaten“-Standard genügen. In den letzten Jahren haben
sich zwei Ansätze zur Standardisierung herausgebildet:
•
sam
genutzten
Metadaten
für
Data-Warehouse-Umgebungen. Es ist
zukunftssicher und offen durch Verwendung
von
objektorientierten •
Schlüssel- und Internettechnologien.
Das Open Information Model CWM integriert drei Schlüsseltechno(OIM) der Meta Data Coalition logien und Industriestandards:
(MDC)
• XML — die eXtensible Markup
schreibung von Tätigkeiten, die
im Rahmen von Analysen durchgeführt werden.
Management: Der ManagementBereich umfasst Metamodelle,
die zur Beschreibung der Prozesse innerhalb eines Data Warehouse genutzt werden.
Der Einsatz von Werkzeugen auf der
Basis eines weithin akzeptierten Standards im Metadatenumfelds garantiert
weitgehend Investitionssicherheit in
die Zukunft.
2.7 Datenschutz
Abbildung 8: Architektur des Common Warehouse Metamodel
•
Deshalb sind die den Datenschutz
betreffende Fragestellungen zwingend
UML — Unified Modeling Lan- im Vorfeld zu klären und daraus reguage,
ein OMG-Standard
sultierende Einschränkungen ggf. zu
• MOF — Meta Object Facility, berücksichtigen:
ein OMG-Standard
• Was soll, was darf gespeichert
werden?
Die
CWM-Architektur
(vgl.
Abbildung 8) besteht aus den Schich- • Für welchen Zeitraum dürfen Daten Management, Analysis, Resource,
ten gehalten werden?
Foundation sowie Object Model und
deckt damit alle Bereiche eines Data • Ist der Wahrheitsgehalt der Daten
sichergestellt?
Warehouse ab. Für das Data Warehousing stellen die einzelnen Ebenen • Werden gespeicherte Daten richaufeinander aufbauende, aber voneintig interpretiert?
ander logisch abgrenzbare Bereiche
• Ist der Zugang zu den Daten abdar.
gesichert?
• Foundation: Der FoundationBereich enthält grundlegende • Wann verletzt die Datenanalyse
die Privatsphäre des Kunden?
Metamodelle, wie zum Beispiel
Datentypen, die als Basis anderer Der Datenschutz beschäftigt sich mit
den rechtlichen Regelungen zum
Bereiche dienen.
Schutz von Persönlichkeit, Privat• Resource: Im Resource-Bereich
sphäre und der informationellen
finden sich Metamodelle zur BeSelbstbestimmung.
schreibung von Quell- und Zieldatenstrukturen, wie z.B. relatio- Wer Datenschutz betreibt, will somit
nalen Datenbanken oder XML- in erster Linie nicht Daten schützen,
sondern die Privatsphäre von PersoDateien.
nen. Aufgabe des Datenschutzes ist es
• Analysis: Der Analysis-Bereich
daher, das Recht des Einzelnen zu
beinhaltet Metamodelle zur Beschützen, grundsätzlich selbst über die
Common Warehouse Metamodel
(CWM) der Object Management •
Group (OMG)
Die MDC hat sich mittlerweile aufgelöst und arbeitet in der OMG am
CWM weiter. Der OIM-Ansatz ist
somit gescheitert. Damit hat sich
CWM als der industrieweite de facto
Standard für den Austausch von Metadaten im Data-Warehouse-Umfeld
etabliert.
Das CWM definiert einen Metadatenstandard für alle wichtigen Anwendungsbereiche eines Data Warehouse,
so dass es einen Grundstein für die
Operabilität von Metadaten in Data
Warehouses legt.
Durch die Unterstützung seitens vieler
namhafter Hersteller ist zu erwarten,
dass das CWM sich zukünftig als das
Austauschformat in der Praxis durchsetzen wird. Die OMG wurde 1989
von 11 Unternehmen gegründet und
umfasst mittlerweile 800 Unternehmen, Forschungsinstitute und Organisationen.
Das CWM umfasst eine komplette
Spezifikation der Syntax und Semantik zum Im- und Export von gemein-
Schlagworte,
wie
analytisches
Customer Relationship Management
(aCRM), kundenzentrisches Data Warehouse und Informationsflut führen
zu einem „Warnsignal“ beim Datenschutzbeauftragten (Möller 1998).
Das Data-Warehouse-Konzept bewegt
sich im Spannungsfeld zwischen der
gewinnbringenden Nutzung von Kundendaten einerseits und der Angst des
individuellen Anwenders andererseits,
als „gläserner“ Kunde ausgebeutet zu
werden.
Language,
ein W3C-Standard
Preisgabe und Verwendung seiner •
Daten zu bestimmen.
In Abgrenzung dazu befasst sich Datensicherheit mit dem Schutz der gespeicherten Daten vor unbefugtem
Zugriff.
Die gesetzlichen Regelungen für den
Datenschutz sind national und regional äußerst unterschiedlich ausgeprägt. Während in Deutschland auf
Landessowie auf Bundesebene
(Bundesdatenschutzgesetz,
BDSG)
detaillierte Vorschriften existieren,
gibt es z.B. in den USA kein allgemeines Datenschutzgesetz. Für spezielle Ausprägungen, wie z.B. dem
Telekommunikationsbereich sind in
Deutschland weitere Sonderregelungen vorhanden.
Verstöße gegen das Bundesdatenschutzgesetz können zu Straf- und
Bußgeldverfahren mit bis zu einem
Jahr Gefängnis und ca. 25.000 Euro
Geldbuße führen.
Wesentlich für den Datenschutz ist es,
ob es sich bei den gespeicherten Daten um „Personendaten“, d.h. von
eindeutig identifizierten und somit bestimmbaren Personen, handelt, denn
nur sie sind vom Datenschutz erfasst. •
Bestimmbarkeit ist gegeben, wenn die
Daten mittels zusätzlicher Informationen einer bestimmten Person zugeordnet werden können.
Die Verarbeitung personenbezogener
Daten in einem Data Warehouse ist
mit einer Vielzahl von Problemen verbunden:
•
Eine Verarbeitung und Nutzung
personenbezogener Daten ist
demnach nur zulässig, wenn sie
durch das BDSG oder eine andere
Rechtsvorschrift erlaubt oder die
betroffene Person eingewilligt
hat. Sie unterliegt demnach
grundsätzlich einem Verbot mit
Erlaubnisvorbehalt. Die Wah- •
rung des Rechts auf informationelle Selbstbestimmung überlässt
dem einzelnen Menschen grundsätzlich die Entscheidung, ob und
wie seine Person betreffende Daten verarbeitet werden (Einwilligung). Für den Betroffenen muss
jederzeit transparent sein, welche
Daten über ihn gespeichert sind,
d.h. er kann z.B. eine Auskunft
bzw. Bestätigung über seine gespeicherten Daten einfordern.
Die personenbezogenen Daten
können grundsätzlich nur für einen zuvor vereinbarten Zweck
genutzt werden. Dieser Zweck ist
meist mit einem konkreten Vertrag verknüpft. Diese Form der
Zweckbestimmung ist jedoch im
Data-Warehouse-Umfeld problematisch. Durch die natürliche
Evolution eines Data Warehouse
werden die Daten häufig später
anders genutzt als zu Anfang
festgelegt. Dies liegt an den zu
Beginn noch nicht vorgesehenen
Benutzern mit zum Teil nicht klar
festgelegten Zielen. Diese Loslösung vom ursprünglichen Verwendungszweck bedarf wiederum der Einwilligung der Betroffenen. Beispielsweise müssten
eine Klassifikation von unterschiedlichen Kundentypen und
darauf aufbauende gezielte Marketing- und Werbemaßnahmen
im
Hinblick
auf
CRMAktivitäten als Zweck formuliert
sein. Analog ist das Aufspüren
von Zusammenhängen mittels
Data-Mining-Aktivitäten zu betrachten.
Einwilligung der Betroffenen gebunden.
•
Trotz des Weglassens der identifizierenden Merkmale und des
Namens kann der Personenbezug
in der Regel trotzdem mit
vertretbarem Aufwand an Zeit,
Kosten
und
Arbeitskraft
wiederhergestellt werden und
somit
liegen
keine
anonymisierten,
sondern
wiederum personenbezogene Daten vor.
Aufgrund
der dargestellten Probleme
ist streng genommen zu argumentieren, dass für das Betreiben eines Data
Warehouse mit personenbezogenen
Daten derzeit keine Rechtsgrundlage
existiert. Somit besteht das latente Risiko einer Stillegung des gesamten
Data-Warehouse-Prozesses auf zunächst unbestimmte Zeit, wenn personenbezogene Daten in größerem Umfang gespeichert werden. Eine Verarbeitung personenbezogener Daten im
Data Warehouse und deren Verwendung zum Data Mining ist deshalb nur
eingeschränkt möglich.
Folgende Lösungsansätze sind im
Rahmen des Datenschutzes zu beachGrundsätzlich unterscheidet sich ten, um die dargestellte Problematik
der Zweck im Data-Warehouse- abzumildern:
Umfeld klar von der Datenerhe- • Da ein Data Warehouse zur Entbung in den operativen Systemen.
scheidungsunterstützung
und
Der Zweck „Data Warehousing“
nicht zur operativen Steuerung
ist zu pauschal und nicht konkret
eingesetzt wird, ist die Speichegenug. Der Zweck kann zudem
rung von personenbezogenen Daauch nicht „Vertrag“ sein. Erten nur eingeschränkt oder überschwerend kommt hinzu, dass die
haupt nicht nötig. Hier bietet sich
Navigationsmöglichkeiten durch
das Konzept der Anonymisierung
OLAP-Analysen ein nahezu bean. Sie dient der Veränderung
liebiges in Beziehung setzen von
personenbezogener Daten derart,
Merkmalen ermöglichen. Es werdass die Einzelangaben über perden gerichtete Analysen auf unsönliche oder sachliche Verhältterschiedlichen Navigationspfanisse nicht mehr oder nur mit eiden im Sinne von „Surfen“ in den
nem unverhältnismäßig großen
Datenbeständen erlaubt.
Aufwand an Zeit, Kosten und
Arbeitskraft einer bestimmten
In Konzernen besteht großes Inteoder bestimmbaren Person zugeresse daran, Data-Warehouseordnet werden können. Kein unSysteme konzernweit einzusetverhältnismäßig großer Aufwand
zen. Ein Konzern stellt jedoch
liegt z.B. vor, wenn eine Rekeine einheitliche datenverarbeiIdentifizierung über Kundentende Stelle dar. Vielmehr ist jenummern vorgenommen werden
des juristisch selbständige Tochkann. Der Aufwand für die Entterunternehmen eine solche Stelschlüsselung muss im Bezug auf
le. Daher ist jede Datenweitergaden Wert der Information als sehr
be an bzw. der Datenabruf durch
hoch einzustufen sein (unverhältandere Tochterunternehmen des
nismäßiger Aufwand). In diesem
Konzerns bzw. an die KonzernZusammenhang spricht man von
mutter eine Übermittlung an Dritte und somit wiederum an die
•
proaches to Prototyping, Springer,
faktischer Anonymisierung bzw. Projekten zunächst immer geprüft
Berlin, 1992.
werden sollte, ob die Verarbeitung
von Pseudoanynomisierung.
personenbezogener
Daten
wirkliche
[Balz98] Balzert, H.: Lehrbuch der SoftSind nicht anonyme Daten zwinware-Technik
–
Softwaregend nötig, ist eine Einwilligung notwendig ist, oder ob die VerarbeiManagement,
Softwaredes Kunden mit einem klar defi- tung von anonymen Daten ausreicht.
nierten Zweck nötig. Hierbei ist
zu beachten, dass der Betroffene
über die Bedeutung seiner Einwilligung aufgeklärt werden
muss, um rechtskonform in die
Datenverarbeitung einwilligen zu
können. Hierzu gehört die Information des Betroffenen über den
Zweck der Verarbeitung. Allgemein gehaltene Erläuterungen,
wie solche, dass die Daten zu
Werbezwecken verarbeitet werden, sind insoweit unzureichend.
•
Um den Kunden zu einer Einwilligung zu bewegen, können
Grundprinzipien des Permission
Marketings eingesetzt werden. In
diesem Zusammenhang sind vor
allem folgende Prinzipien zu respektieren:
o Kundennutzen
o Qualität: Die Daten sind
immer richtig und auf dem
neusten Stand.
o Konsens: Die Daten werden
nur zu den Zwecken eingesetzt, denen der Kunden zugestimmt hat.
Qualitätssicherung, UnternehmensAls Konsequenz sollte weiterhin der
modellierung, Springer, Berlin, 1998.
Datenschutz nicht mehr nur als notwendiges Übel verstanden werden, Informationsbedarfsanalyse:
sondern als wichtiges und unverzichtbares Merkmal der Vertrauensbildung [BoUT99] Böhnlein, M., Ulbrich-vom
Ende, A., Tropp, G.: CEUS- Entwickund Differenzierung gegenüber den
lung eines Data Warehouse-Systems
Kunden und Konkurrenten.
3. Zusammenfassung und
Ausblick
Die vorgestellten Themenbereiche
und die damit verbundenen Todsünden sind nach unserem Ermessen die
häufigsten Ursachen für Probleme bei
der
Abwicklung
von
DataWarehouse-Vorhaben, die sogar zu
einem Scheitern des gesamten Projektes führen können. Wir hoffen, dass
wir durch die Problembeschreibungen
sowie die Skizzierung von Lösungsansätzen einen Denkanstoss bei der
Beurteilung des eigenen DataWarehouse-Vorhabens geliefert haben. Zur Vertiefung der Problemstellung sind im Folgenden, gegliedert
nach den Themenbereiche, weiterführende Literaturquellen genannt.
o Transparenz: Der Kunde 4. Literatur
weiß, was mit seinen Daten
Ganzheitliche Konzeption:
geschieht.
o Sicherheit: Mit den Daten
wird sorgfältig und vertrauensvoll umgegangen.
o Weitergabe: Eine Weitergabe der Daten findet ohne Einwilligung des Kunden nicht
statt.
o Zugriff: Der Kunde hat die
Option, seine Daten einzusehen und zu verändern, ggf.
auch zu löschen.
•
für die bayerischen Hochschulen, 1.
Workshop des GI-Arbeitskreises Modellierung und Nutzung von Data Warehouse-Systemen auf der MobIS'1999, Bamberg, 1999.
[Druc95] Drucker, P.F.: Managing in a
Time of Great Change, Truman Talley
Books, New York, 1995.
[Nona91] Nonaka, I.: The KnowledgeCreating Company, in: Harvard Business Review, 69. Jg., Nr. 6, November-Dezember 1991, S. 96-104.
[Schi01] Schirp, G.: Anforderungsanalyse
im Data-Warehouse-Projekt: Ein Erfahrungsbericht aus der Praxis, HMD,
Heft 22, 2001.
Projektteam:
[DeLi99] DeMarco, T., Lister, T.: Wien
wartet auf DICH – Der Faktor
Mensch im DV-Management, 2. Aufl.,
Hanser, München, 1999.
[CoAb96] Corey, M.J., Abbey, M.: Oracle
Data Warehousing, Oracle Press,
Berkeley, 1996.
Datenqualität:
[Gard98] Gardner, S. R.: Building the
Data Warehouse, in: Communications [Engl99] English, L.: Improving Data
Warehouse and Business Information
of the ACM, 41. Jg., Nr. 9, 1998, S.
Quality – Methods for reducing costs
52-60.
and increasing profits, Wiley, New
[Kach99] Kachur, R.J.: Planning and ProYork, 1999.
ject Management For the Data Ware[Engl02] English, L.: Essentials for Effechouse, DM Direct, Februar 1999.
tive Information Quality Management,
[Kurz99] Kurz, A.: Data Warehousing –
Data-Warehouse-Forum,
St.
8th
Enabling Technology, MITP, Bonn,
Gallen, Schweiz, 2002.
1999.
[Gard97] Gardyn, E.: A Data Quality
[KRRT98] Kimball, R., Reeves, L., Ross,
Handbook for a Data Warehouse, in:
M., Thornthwaite, W.: The Data
Strong, D.M., Beverly, K.K. (Hrsg.):
Warehouse Lifecylce Toolkit, Wiley,
Proceedings of the 1997 Conference
New York, 1998.
on Information Quality, Massachussetts, 1997, S. 267-290.
Um sich bereits frühzeitig im Data-Warehouse-Prozess abzustimmen und späteren Problemen aus
dem Weg zu gehen, ist sowohl Projektmgt und Vorgehensmodelle:
die Einbindung des Betriebsrats
als auch die Hinzuziehung des [Boe88] Boehm, B.W.: A Spiral Model of
Software Development and Enhancejeweiligen Datenschutzbeauftragment, in: IEEE Computer, 21. Jg., Nr.
ten anzuraten.
5, 1988, S. 61-72.
[HuLW99] Huang, J., Lee, Y.W.,, Wang,
R.Y.: Quality Information and Knowledge, Prentice Hall, Upper Saddle
River, 1999.
Zusammenfassend lässt sich festhal- [BKKZ92] Budde, R., Kuhlenkamp, K., Metadatenmanagement:
ten, dass bei der Planung von DataMathiessen, L., Züllighoven, H.: ApWarehousing- und Data-Mining-
[DSMR00] Do, H.; Stöhr, T.; Müller, R.;
Rahm, E.: Metadaten-Management im
Data Warehouse-Bereich, 2. Workshop des GI-Arbeitskreises Modellierung und Nutzung von Data Warehouse-Systemen, Freiburg, 2000.
[StVV99] Staudt, M., Vaduva, A., Metterli, T.: Metadata Management and Data Warehousing, Technical Report 21,
Institut für Informatik, Universität Zürich, 1999.
[OMG02] Object Management Group:
Data Warehousing, CWM™ and
MOF™
Resource
Page,
http://www.omg.org/cwm, 2002.
Datenschutz:
[Moel98] Möller, F.: Data Warehouse als
Warnsignal an den Datenschutzbeauftragten, in: Datenschutz und Datensicherung, 22. Jg., Nr. 10, 1998, S. 555560.
[o.V.00] Data Warehouse, Data Mining
und Datenschutz - Entschließung der
59. Konferenz der Datenschutzbeauftragten des Bundes und der Länder
vom
14./15.
März,
http://www.datenschutz-berlin.de/doc
/de/konf/59/datawa.htm, 2000.
[Schw99] Schweizer, A.: Data Mining,
Data Warehousing – Datenschutzrechtliche Orientierungshilfen für Privatunternehmen, Orell Füsli, Zürich,
1999.
Dr. Michael Böhnlein, T-Systems Nova
GmbH, Merianstr. 32, D-90409 Nürnberg,
Tel. (0911) 5195-308, E-Mail:
[email protected]
Dr. Andreas Bauer, T-Systems Nova
GmbH, Merianstr. 32, D-90409 Nürnberg,
Tel. (0911) 5195-247, E-Mail:
[email protected]
82
Beiträge des Arbeitskreises WIWI-EPK:
Geschäftsprozessmanagement mit
Ereignisgesteuerten Prozessketten
83
84
GI-Arbeitskreis & Workshop-Bericht
EPK 2003 - Geschäftsprozessmanagement mit
(http://www.epk-community.de)
GI-Arbeitskreis WI-EPK
Ereignisgesteuerte Prozessketten (EPK) haben sich in der Praxis als Beschreibungsmittel für
betriebliche Abläufe etabliert. Im Jahre 1997 wurde mit dem Aufbau der Arbeitsgruppe
"Formalisierung und Analyse Ereignisgesteuerter Prozessketten (EPK)" ein erster Schritt
unternommen, einen organisatorischen Rahmen für Interessenten und Autoren wesentlicher
Forschungsarbeiten zu schaffen und regelmäßige Arbeitstreffen durchzuführen (Initiatoren:
M. Nüttgens, A. Oberweis, F. J. Rump). Im Jahr 2002 wurden die Arbeiten der "informellen“
Arbeitsgruppe in den GI-Arbeitskreis "Geschäftsprozessmanagement mit Ereignisgesteuerten
Prozessketten (WI-EPK)" der GI-Fachgruppe WI-MobIS (FB-WI) in Kopperation mit der GIFachgruppe EMISA (FB-DBIS) und der GI-Fachgruppe Petrinetze (FB-GInf) überführt und
inhaltlich erweitert.
Themenschwerpunkte des GI-Arbeitskreises sind u.a.:
• EPK-Basiskonzepte (Syntax und Semantik)
• EPK-Verifikationskonzepte (Anforderungsdefinition und -analyse)
• EPK-Modellierungskonzepte (Metamodelle, Vorgehensmodelle etc.)
• EPK-Anwendungskonzepte (Simulation, Prozesskostenrechnung, Prozessanalyse,
Referenzmodellierung, Re-(Dokumentation), Qualitätsmangement, Riskmanagement,
Workflowmanagement, Wissensmanagement etc.)
• EPK-Transformationskonzepte (UML-Diagramme, Petri-Netze, Zustandsautomaten,
Netzplantechnik etc.)
• EPK-Schnittstellenkonzepte (XML/XMI, etc.)
• EPK-Werkzeugkonzepte (Prototypen und Produkte)
Workshops des GI Arbeitskreises (Stand Oktober 2003):
• 1. Workshop „EPK 2002 - Geschäftsprozessmanagement mit Ereignisgesteuerten
Prozessketten“, 21.-22. November 2002, Trier
• 2. Workshop „EPK 2003 - Geschäftsprozessmanagement mit Ereignisgesteuerten
Prozessketten“, 08. Oktober 2003, Bamberg
Die Aktivitäten des Arbeitskreises werden unter der Internetadresse http://www.epkcommunity.de dokumentiert (aktuell: 120 Mitglieder). Der Arbeitskreis soll Praktikern und
Wissenschaftlern als Forum zur Kontaktaufnahme, zur Diskussion und zum
Informationsaustausch dienen. Insbesondere Praktiker aus dem Bereich des Geschäftsprozessmanagements mit Ereignisgesteuerten Prozessketten sind herzlich zur Mitarbeit
eingeladen. Die Bereitstellung von Informationen und die unverbindliche und kostenfreie
Mitgliedschaft im Arbeitskreis erfolgt durch Eintragung in ein Web-Formular unter
http://www.epk-community.de.
Dr. Markus Nüttgens (Sprecher)
E-mail:[email protected]
Prof. Dr. Frank J. Rump (Stellv. Sprecher)
E-mail:[email protected]
85
GI-Workshop EPK 2003
Am 08. Oktober 2003 wurde an der Otto-Friedrich-Universität Bamberg im Vorfeld der
MobIS 2003 der 2. GI-Workshop „EPK 2002 - "Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten“ in Kooperation mit der GI-Fachgruppe EMISA (FB-DBIS) und
der GI-Fachgruppe Petrinetze (FB-GInf) durchgeführt. Mit einem Einladungsvortrag, fünf
Fachvorträgen und zwei Diskussionsbeiträgen und ca. 25 Teilnehmern aus dem
Hochschulumfeld und der Praxis wurde ein ansprechendes Diskussionsforum geschaffen.
In seinem Einladungsvortrag „Wertorientierte Geschäftsprozessgestaltung - Erfahrungsbericht
aus dem Bankensektor“ konnte Herr Dr. Gerhard Keller einen weiten Bogen von der
Entstehung bis zu aktuellen Problemstellungen der Verwendung von EPKs in der Praxis
spannen. Anhand eines Fallbeispiels aus der Praxis wurde die Definition einer
Prozessarchitektur, die Ableitung und Wiederverwendung von Prozessbausteinen und die
Prozessoptimierung mit Dokumenten thematisiert. Der Vortrag schloss mit einer kritischen
Würdigung von Trends in der Prozessoptimierung und einem Plädoyer für schlanke und
pragmatische Bewertungskonzepte.
Der elektronische Tagungsband zum Workshops kann unter http://www.epk-community.de
abgerufen werden:
Fachbeitäge
•
Ekkart Kindler (Uni Paderborn): On the semantics of EPCs: A framework for
resolving the vicious circle
•
Jan Mendling (Uni Trier), Markus Nüttgens (Uni des Saarlandes): EPC Syntax
Validation with XML Schema Languages
•
Jörg Becker, Lars Algermissen, Björn Niehaves (Uni Münster): Prozessmodellierung
in eGovernment-Projekten mit der eEPK
•
Jörg Becker, Patrick Delfmann, Thorsten Falk, Ralf Knackstedt (Uni Münster):
Multiperspektivische ereignisgesteuerte Prozessketten
•
Peter Fettke, Peter Loos (Uni
Mainz):
Ontologische
Evaluierung
von
Diskussionsbeiträge
•
Heinrich Seidlmeier (FH Rosenheim): Dokumentenmanagement-Prozesse
Modellierung der "versteckten" Prozesse mit ARIS-eEPK
•
Kristof Schneider, Oliver Thomas ((IWi/DFKI Saarbrücken): Kundenorientierte
Dienstleistungsmodellierung mit Ereignisgesteuerten Prozessketten
-
Auch das abendliche Treffen in der Bamberger Altstadt (Weltkulturerbe) und der
obligatorischen Besuch des Brauereiausschank Schlenkerla mit seinem „Aecht Schlenkerla
Rauchbier“ bleiben sicherlich in guter Erinnerung. Ein Dank insbesondere den AutorInnen,
den Mitgliedern des Programmkomitees und dem lokalen Organisationsteam der MobIS 2003
für die Beträge zur Realisierung des Workshops.
86
Fachbeitrag
87
88
Konzeption eines XML-basierten Austauschformates für
Ereignisgesteuerte Prozessketten (EPK)
Jan Mendling
Markus Nüttgens
Wirtschaftsuniversität Wien
[email protected]
Universität des Saarlandes
[email protected]
Zusammenfassung: Der Erfolg und die schnelle Verbreitung des XML-Konzeptes
haben dazu geführt, dass die Hersteller von Werkzeugen zur Geschäftsprozessmodellierung zunehmend XML Import- und Export-Schnittstellen anbieten. Die Existenz produktspezifischer Schnittstellen ist aber keine hinreichende Bedingung für
einen XML-basierten Modelldatenaustausch über Produktgrenzen hinweg. Ein wesentlicher Lösungsansatz besteht in der Entwicklung und Unterstützung von XMLbasierten Austauschformaten. Dieser Beitrag befasst sich mit dem Konzept einer
EPK Markup Language (EPML) als XML-basiertes Austauschformat für Ereignisgesteuerte Prozessketten (EPK).
1
XML-basierter Modelldatenaustausch
Seit den 1990er Jahren haben sich Werkzeuge zur Modellierung von Geschäftsprozessen
(Business Process Modelling) zu einem eigenständigen Marktsegment entwickelt. Eine
Studie von Gartner Research aus dem Jahr 2002 bezieht sich auf 35 größere WerkzeugHersteller und prognostiziert, dass sich diese Zahl in den nächsten Jahren tendenziell
halbieren wird [Ga02]. Interoperabilität und die Unterstützung von Standards wird hierbei als ein wichtiges Selektionskriterium genannt. Die Unterstützung von XML-basierten
Import- und Export-Schnittstellen wird auch von den Werkzeugherstellern selbst zunehmend als geschäftskritische Produkteigenschaft angeführt [MN03b]. Dabei sind zwei
Stufen von Standardunterstützung zu unterscheiden. Auf der einen Seite wird XML als
standardisiertes Repräsentationsformat für die Definition von Austauschformaten benutzt, was wir als schwache Standardunterstützung bezeichnen. Andererseits können
standardisierte Inhaltsformate unterstützt werden, welches wir als starke Standardunterstützung bezeichnen.
Schwache Standardunterstützung beschreibt eine Strategie eines Werkzeugherstellers,
ein produktabhängiges und damit proprietäres XML Schema bereitzustellen. In einem
Umfeld heterogener Werkzeuge, die schwache Standardunterstützung bieten, benötigt
man Transformationsprogramme, um ein Modell von Tool A nach Tool B zu übertragen.
Ein wesentlicher Vorteil des XML-Einsatzes in diesem Szenario ist die Verfügbarkeit
spezieller Anwendungen. Mit Hilfe von XSLT [Cl99] existiert beispielsweise eine
Skript-Sprache für die Transformation von XML-Daten, die dem Programmierer das
89
„Parsen“ des Eingabe-Dokumentes, die Definition von Transformationsregeln und die
Generierung des Outputs erheblich vereinfachen. Das grundlegende Problem der Heterogenität der produktspezifischen XML-Daten ist damit allerdings nicht gelöst.
Die starke Standardunterstützung setzt die Existenz anerkannter XML-Austauschformate
und eine Unterstützung durch die Werkzeughersteller voraus. Für den Anwender ist dies
ein effizienteres Szenario. Spezialisierte Werkzeuge können für unterschiedliche Aufgaben genutzt werden, wobei das standardisierte Austauschformat die Heterogenität überbrückt. Derartige Standards haben sich bereits erfolgreich für eine Reihe von Modellierungskonzepten etabliert. Für die Unified Modeling Language (UML) [OMG03a] wurde
XML Metadata Interchange (XMI) [OMG03b] und für Petri Netze eine Petri Net Markup Language (PNML) spezifiziert [Bi03]. Für die Geschäftsprozessmodellierung mit
Ereignisgesteuerten Prozessketten (EPK) [KNS92] befindet sich derzeit eine vergleichbare Spezifikation einer EPK Markup Language (EPML) in der Entwicklung [MN02,
Me03, MN03b, MN03c].
Die Etablierung eines XML-Standardformates für EPK-Modelle hat aufgrund der zunehmenden Verbreitung und Akzeptanz des EPK-Konzeptes ein hohes Anwendungspotenzial. Der Austausch von Geschäftsprozessmodellen kann dabei unter zwei Dimensionen erfolgen: Der horizontale Modelldatenaustausch hat die Integration von Modellierungswerkzeugen zum Gegenstand, wohingegen ein vertikaler Modelldatenaustausch auf
die Integration von Modellierungswerkzeugen mit Ausführungswerkzeugen wie z.B.
Simulationswerkzeugen, Workflow-Engines oder Monitoring-Diensten abzielt [Wf02].
Damit kann ein wesentlicher Beitrag zur Integration des Entwicklungszyklus von Prozessmodellierung und –implementierung geleistet werden.
Bislang ist der Markt für Modellierungswerkzeuge durch eine Strategie der schwachen
Standardunterstützung mit proprietären XML-Schnittstellen gekennzeichnet. Die Entwicklung von XML-Austauschformaten wie EPML sollte mittelfristig ein Umschwenken
in Richtung einer starken Standardunterstützung begünstigen. Ein Zwischenschritt kann
auch in der Nutzung von XML-Austauschformaten als intermediäres Format liegen. Bei
einer größeren Anzahl von Werkzeugen kann ein gemeinsames intermediäres Format die
Anzahl der Transformationsprogramme maßgeblich verringern [WHB02].
Der Beitrag diskutiert, wie solch ein Austauschformat für EPKs entworfen werden kann.
Im zweiten Kapitel werden allgemeine XML-Designprinzipien und Entwurfsprinzipien
für EPML besprochen. Kapitel 3 behandelt Prozess- und Graphrepräsentation in XML.
Hier werden verschiedene Darstellungsmöglichkeiten anhand vorhandener Spezifikationen erläutert. In Kapitel 4 werden die syntaktischen Elemente eines EPK-Prozesses
dargestellt. Dies umfasst auch Aspekte der Verwaltung von Modellhierarchien. Kapitel 5
bietet einen Überblick über die graphische Repräsentation wie etwa Koordinatensystem,
Positionsangaben und Layout-Informationen. In Kapitel 6 wird eine Übersicht über Sichten auf Prozesse gegeben. Das siebte Kapitel schließt mit einer Zusammenfassung und
einem Ausblick.
90
2
EPML Design Prinzipien
Das Ziel von EPML ist es, ein werkzeug- und plattformunabhängiges Austauschformat
für EPKs zur Verfügung zu stellen. Daraus ergeben sich drei Fragen. Zum ersten stellt
sich die Frage, was genau im Detail modelliert werden soll. Zum zweiten impliziert dies
die Frage nach den übergeordneten Richtlinien, wie Sachverhalte in XML ausgedrückt
werden sollen. Zum dritten steht die Frage im Raum, welche generellen Prinzipien die
Modellierung leiten sollen. Wir werden diese Fragen der Reihe nach aufgreifen, beginnend mit der dritten, gefolgt von der zweiten, die beide in diesem Kapitel angesprochen
werden.
2.1
Allgemeine EPML Design-Prinzipien
Einige der veröffentlichten XML Spezifikationen beschreiben explizit ihre DesignPrinzipien wie z.B. das ASC X12 Reference Model for XML Design (X12) [AN02].
Dieses beschreibt ein siebenschichtiges Model für die Spezifikation von Geschäftsdokumenten. Die Definition von X12 wurde von vier abstrakten Design-Prinzipien geleitet:
Ausrichtung an anderen Standards, Einfachheit, Vordefiniertheit und begrenzte Freiräume. Ausrichtung an anderen Standards (Alignment) bezieht sich auf die spezifische Domäne der Geschäftsdokumente, zu der auch andere Organisationen wie OASIS und
UN/CEFACT, das World Wide Web Consortium und OASIS UBL Beiträge leisten.
Einfachheit (Simplicity) ist ein domänenunabhängiges Kriterium. Es verlangt, dass spezifische Aspekte und Wahlmöglichkeiten auf ein Minimum reduziert werden. Vordefiniertheit (Prescriptiveness) bezieht sich wiederum auf Geschäftsdokumente. Dieses
Prinzip empfiehlt es, eher mehr präzise und spezifische Dokumente zu definieren als
wenige allgemeine. Begrenzte Freiräume (Limit Randomness) bezieht sich auf den
Gebrauch gewisser Konstrukte von XML Schema Sprachen, insbesondere Operatoren,
die verschiedene Wahlmöglichkeiten in der Syntax eröffnen. Der Einsatz solcher Konstrukte sollte auf ein Minimum reduziert werden. Dieser Aspekt bezieht sich auf den
Entwurf von XML Vokabularien im Allgemeinen.
Der PNML-Ansatz wird von den Prinzipien Flexibilität, Eindeutigkeit und Kompatibilität geleitet [Bi03]. Flexibilität (Flexibility) ist ein wichtiger Aspekt für Petri-Netze, da
jegliche Arten von heute diskutierten als auch zukünftigen Klassen von Petri Netzen
abbildbar sein sollen. Dies wird über Labels erreicht, die zur Annotation von Kanten und
Knoten benutzt werden können. Eindeutigkeit (No Ambiguity) bezieht sich auf das Problem der Standardisierung dieser Labels. Dafür werden Petri Net Type Definitions eingesetzt, um erlaubte Labels eines speziellen Netztypes zu beschreiben. Kompatibilität
(Compatibility) beschreibt Probleme, die sich durch semantisch äquivalente Labels ergeben, die in verschiedenen Petri-Netztypen benutzt werden. Diese überlappenden Labels
sollten beim Austausch zwischen verschiedenen Netztypen erhalten bleiben.
Der EPML-Ansatz reflektiert diese verschiedenen Design-Prinzipien. Er wird von den
Prinzipien Lesbarkeit, Erweiterbarkeit, Tool-Orientierung und syntaktische Richtigkeit
geleitet [MN03b]. Lesbarkeit fordert, dass EPML-Elemente und –Attribute intuitive und
sprechende Namen haben. Dies ist wichtig, da EPML-Dokumente nicht nur von Anwen-
91
dungen benutzt werden, sondern auch von Anwendern, die beispielsweise XSLT-Skripte
zur Konvertierung zwischen EPML und anderen XML Vokabularien schreiben. Lesbarkeit steht teilweise in Bezug zu den Prinzipien Einfachheit und begrenzte Freiräume des
X12-Ansatzes. Erweiterbarkeit betrachtet ein Problem, das in gewisser Weise analog zu
der Darstellung verschiedener Petri-Netz-Typen ist. Ein wichtiger Aspekt der EPKModellierung ist die Bereitstellung verschiedener Sichten auf ein Prozessmodell. EPML
soll in der Lage sein, jegliche Arten von Sichten abbilden zu können anstatt sich auf eine
vorgegebene Menge zu beschränken. Tool-Orientierung zielt hauptsächlich auf die graphische Repräsentation von EPK-Modellen. Dies ist eine zentrale Eigenschaft, da Modellierungswerkzeuge eine graphische Benutzerschnitte zur Definition von Prozessen
bereitstellen. EPML soll in der Lage sein, verschiedene Layout- Positionsangaben von
EPK-Elementen abspeichern zu können. Diese Aspekte werden in Kapitel 6 detailliert
aufgegriffen. Syntaktische Richtigkeit befasst sich mit den Elementen der EPK-Syntax
und deren Beziehungen zueinander. Dieser Punkt wird in Kapitel 3 und Kapitel 4 behandelt. Der folgende Abschnitt umfasst allgemeine Richtlinien für das Design von XML
Vokabularien.
2.2
Richtlinien für XML Design
Grundsätzlich können zwei Ansätze zur Begründung von XML Design Richtlinien unterschieden werden: Ein theoretischer, der sich auf Normalformen und informationstheoretische Maßzahlen wie Entropie stützt, und ein pragmatischer, der Empfehlungen bereitstellt, wann und wie welche XML-Sprachkonzepte eingesetzt werden sollen und wie
die Benennung von Elementen und Attributen vorgenommen werden soll.
Der theoretische Ansatz gründet sich auf Erkenntnisse der Datenbank-Theorie. Für relationale Datenbankmodelle wurden Funktionale Abhängigkeit (FD), Mehrwertige Abhängigkeiten (MVD) und Join Abhängigkeit (JD) konzipiert [Bi95]. Um Schemata mit
formal guten Eigenschaften abzuleiten, gibt es Dekompositionsalgorithmen, um verschiedene Stufen von Normalformen zu erreichen. Diese Normalformen beseitigen Redundanzen und Anomalien durch Operationen auf relationalen Daten. Analog hierzu
sind Normalformen für XML (XNF) entwickelt worden [EM01, AL02]. In [AL03] wird
ein informationstheoretischer Ansatz vorgestellt, der die konzeptionelle Lücke zwischen
relationaler und XML-Repräsentation überbrücken kann. Aufbauend auf EntropieMaßen wird ein konzeptunabhängiges Verständnis zwischen Redundanzen und Normalformen erarbeitet. Ein Schema wird als well-designed bezeichnet, wenn es keine Instanzdaten enthalten kann, die weniger als das Maximum an Information bezüglich der
bedingten Entropie tragen [AL03]. Darauf basierend kann gezeigt werden, dass ein
Schema mit lediglich FDs und weder MVDs noch JDs well-designed ist, wenn und nur
wenn es in Boyce-Codd-Normalform ist. FDs für XML-Daten treten dann auf, wenn
Pfade von der Wurzel zu Knoten von anderen Pfaden abhängen. Dementsprechend wird
definiert, dass ein XML Schema bezüglich einer Menge von FDs well-designed ist,
wenn und nur wenn es in XNF ist [AL03]. Eine Verletzung dieser Forderung bedeutet,
dass Redundanzen in der Art vorliegen, dass Pfade zu verschiedenen Knoten führen, die
jedoch denselben Wert haben. Hier hilft ein Normalisierungsalgorithmus, der die Position von Attributen verändert und neue Elemente erzeugt bis XNF erfüllt ist [AL03]. Für
92
den Entwurf von XML Vokabularien bedeutet dies, dass es keine XPath [CD99] Anweisungen geben darf, die eine Knotenmenge mit jeweils demselben Wert zurückgeben. In
diesem Fall ist XNF erfüllt und das Schema ist well-designed.
Pragmatische Ansätze zielen hauptsächlich auf die Erweiterbarkeit und mögliche Freiräume bei der Definition von XML Vokabularien ab. Dokumente von ISO [ISO01],
SWIFT [SW01], MISMO [MIS02] und X12 [AN02] begründen eine Reihe von Regeln,
um Mehrdeutigkeiten in XML Schemata zu minimieren. Diese XML Entwurfsrichtlinien
umfassen Konventionen für Namen, für die Wahl zwischen Attributen und Elementen,
für den Einsatz von speziellen Operatoren von XML Schema-Sprachen und für den
Einsatz von Namespaces. Namenskonventionen beziehen sich auf die Bezeichnung von
Elementen und Attributen. ISO, SWIFT, MISMO, und X12 fordern übereinstimmend
den Gebrauch von ausschließlich englischen Wörtern. Namen können aus mehreren
Wörtern bestehen, die gemäß des so genannten Upper Camel Case abgetrennt werden
sollen (keine trennenden Leerzeichen, sondern jedes einzelne Wort beginnend mit einem
Großbuchstaben). Abkürzungen und Akronyme sollen auf ein Minimum reduziert werden. Stilkonventionen leiten die Entscheidung zwischen Elementen und Attributen. X12
empfiehlt die Benutzung von Attributen für Metadaten und Elemente für Anwendungsdaten [AN02]. In diesem Zusammenhang sollte man identifizierte Schlüsselattribute als
Metadaten auffassen und in Attribute setzen. Dies ermöglicht den DTD-konformen
Gebrauch von ID, IDREF und IDREFS Datentypen und entsprechende key- und keyrefDeklarationen in W3C XML Schema [Be01, BM01]. Des Weiteren wird angemerkt,
dass Attribute zu einer besseren Lesbarkeit des Inhaltes beitragen [Me01, AN02]. Deshalb sollten Daten, die nie erweitert werden können, in Attribute gepackt werden. Schemakonventionen empfehlen bewusst, nur einen Teil der Ausdrucksstärke einer XML
Schema-Sprache einzusetzen. X12 rät beispielsweise, gemischte Inhaltstypen, Substitutionsgruppen und Gruppen-Redefinitionen zu vermeiden. Es sollten u.a. nur benannte
Inhaltstypen und vordefinierte einfache Datentypen benutzt werden. Eine tiefergehende
Diskussion findet sich in [AN02]. Namespace-Konventionen verweisen auf den
Gebrauch von Namespaces in Dokumenten. X12 empfiehlt, explizite NamespaceReferenzen nur für die Wurzel zu benutzen.
Die theoretischen und pragmatischen Ansätze liefern komplementäre Richtlinien für die
Definition „guter“ XML Schemata. Die aufgeführten Richtlinien sind in den EPMLVorschlag eingeflossen. Das folgende Kapitel über Prozessgraph-Repräsentation in
XML beginnt die Reihe der Kapitel, die einzelne Design-Aspekte von EPML vorstellen.
3
Prozessgraph-Repräsentation
Ein Graph ist ein Paar von Knoten V und Kanten E, wobei E eine Untermenge des kartesischen Produktes über V ist. In der Informatik spielen Graphen in den verschiedensten
Bereichen eine Rolle. Zum Beispiel werden Entity-Relationship-Modelle zum konzeptionellen Entwurf von relationalen Datenbanken eingesetzt [Ch76]. Entitäten können
dabei als spezielle Art von Knoten betrachtet werden und Relationships als spezielle
Sorte von Kanten. Ein anderes Beispiel ist die objekt-orientierte Software-Entwicklung.
Die Unified Modeling Language (UML) [OMG03a] erlaubt die Modellierung von Be-
93
ziehungen und Vererbungshierarchien, die ebenfalls als Graphen betrachtet werden können. Graphstrukturen von Software-Programmen werden im Bereich Software Reengineering eingesetzt [FGW03]. Da auch Geschäftsprozessmodelle formal auf gerichteten
Graphen basieren, sollte ein Ansatz zur Repräsentation von EPK-Modellen Erfahrungen
aus diesen Bereichen einbeziehen.
In der Informatik werden verschiedene Datenstrukturen für Graphen diskutiert, hauptsächlich mit Fokus auf die effiziente Ausführung von Graph-Algorithmen. Die drei
grundlegenden Darstellungsformen sind Adjazenzmatrizen, Adjazenzlisten und Kantenlisten [Eb87]. Eine Adjanzenzmatrix repräsentiert einen gerichteten Graphen mit n Knoten mit Hilfe einer n × n Matrix, wobei der Eintrag an der Stelle (i,j) 1 ist, wenn eine
Kante von Knoten i zu Knoten j verläuft, andernfalls ist der Eintrag 0 [Bl03]. Im Gegensatz dazu beschreibt die Adjazenzliste einen gerichteten Graph mit n Knoten als einen
Array von n Knotenlisten. Ein Knoten j ist in der Liste i enthalten, wenn es eine Kante
von Knoten i zu Knoten j gibt. Kantenlisten kommen der Mengendefinition von Graphen
am nächsten. Eine Kante von einem Knoten i zu einem Knoten j wird als ein Paar (i,j)
gespeichert.
Wenn solch eine generische Graph-Datenstruktur in XML ausgedrückt werden soll,
müssen Anpassungen vorgenommen werden, um der Baumstruktur von XML Rechnung
zu tragen. Das bedeutet, dass ID, IDREF, IDREFS Datentypen der Document Type
Definition (DTD) [Br00] oder xs:key, xs:keyref Bedingungen von XML Schema [Be01,
BM01] eingesetzt werden müssen, um beliebige Kanten zu beschreiben. Um Best Practices in der Beschreibung von Graphen mit XML zu identifizieren, wurden eine Reihe von
graphbasierten Konzepten mit einer XML Syntax untersucht, darunter sowohl akademische Vorschläge als auch Industriestandards und werkzeugspezifische Formate. Deren
Graph-Repräsentationen lassen sich in drei Kategorien aufteilen: block-orientierte Repräsentation, Adjazenz-Subelement-Listen und Kanten-Element-Listen.
Die Block-orientierte Repräsentation wird von den Notationen im Bereich Web Services
wie BPML [Ar02] oder BPEL4WS [An03] genutzt. Dieses Paradigma ist inspiriert von
Prozessalgebren wie dem Pi-Calculus [Mi99], die ihnen als theoretischer Rahmen dienen. Block-orientierte Sprachen bieten eine Menge von einfachen (simple in BPML oder
basic in BPEL4WS) und komplexen (complex in BPML oder structured in BPEL4WS)
Operationen, die den Kontrollfluss repräsentieren. Dabei gibt es einige Unterschiede in
der Benennung zwischen BPML und BPEL4WS, die Konzepte sind jedoch sehr ähnlich
[MM03]. Komplexe Operationen ermöglichen die Definition paralleler Ausführung,
Sequenz, Verzweifungen und Schleifen. Sie können ineinander geschachtelt sein. Die
reine Blockstruktur ist jedoch nicht im Stande, beliebige Kontrollflüsse auszudrücken.
Daher besitzen BPML und BPEL4WS zusätzlich Links, die solche Kontrollflussbeschreibungen ermöglichen. Ein Vorteil der Block-Orientierung liegt darin, dass Code
(wenn nicht zu tief geschachtelt) dank seiner sequentiellen Darstellung gut lesbar ist und
mit wenigen Befehlen recht komplexe Sachverhalte ausgedrückt werden können. Der
Nachteil besteht darin, dass Block-Orientierung mit anderen Konzepten wie Links gemischt werden muss, um bestimmtes Verhalten abbilden zu können und somit für eine
graphische Aufbereitung schlecht geeignet ist. Es sind komplexe Abbildungen zwischen
Modellierungswerkzeugen und block-orientierter Darstellung erforderlich, wie sie beispielsweise im Rahmen der Business Process Modelling Notation (BPMN) [Wh03]
94
diskutiert werden. EPML ist jedoch auch mit dem Fokus auf graphische Modellierungswerkzeuge konzipiert. Somit ist eine block-orientierte Repräsentation weniger geeignet.
Adjazenz-Subelement-Listen beschreiben einen Prozessgraphen mit Hilfe einer ungeordneten Liste von Knoten, die über ein ID-Attribut identifiziert werden. Eine Kante wird
als Subelement ihres Ausgangsknotens abgespeichert. Die Kante besitzt ein Attribut, das
eine ID-Referenz auf den Zielknoten enthält. Diese Repräsentation wird beispielsweise
vom XML Import- und Exportformat der ARIS-Werkzeugfamilie benutzt [IDS01,
IDS03a]. Sein Vorteil liegt darin, dass man einen schnellen Überblick über die von einem Knoten ausgehenden Kanten hat. Jedoch reduziert die Benutzung von IDReferenzen die Lesbarkeit. Ein weiterer Nachteil gründet sich auf die konzeptionellen
Implikationen dieses Darstellungsstils: Es können keine Kanten gespeichert werden, die
nicht zumindest einen Ausgangsknoten haben. Im Rahmen der Geschäftsprozessmodellierung kann es jedoch durchaus sinnvoll sein, Prozessmodelle auszutauschen, die noch
nicht fertig gestellt sind bzw. Kanten enthalten, die keinen Start- und nur einen Endknoten haben. Eine Adjazenz-Subelement-List kann solche Informationen nicht abbilden.
Kanten-Element-Listen stehen in enger Beziehung zu einer mengenorientierten Definition von Graphen. Kanten werden als first-class Objects behandelt und enthalten Felder
für ID-Referenzen auf den Ausgangs- und den Zielknoten. Spezifikationen wie GXL
[WKR02] und PNML [WK02] unterstreichen dies, indem sie Kanten genau wie Knoten
ein ID-Attribut zuteilen. Die Kanten-Element-Listen-Repräsentation ist weit verbreitet.
Sie wird von GXL, PNML, Visio’s VDX [Mi03], XMI [OMG03b] und vom XPDLFormat der Workflow Management Coaltion [Wf02] unterstützt. Ein Vorteil dieser Darstellung ist ihre Flexibilität. Beliebige Graphen können mit ihr beschrieben werden und
es können Kanten ohne Anfangs- und Endknoten gespeichert werden. Ein Nachteil besteht durch den Einsatz von IDs und IDREFs, die die Lesbarkeit des Formates beeinträchtigen.
Die Paradigmen zur Prozessrepräsentation betreffen die EPML Design-Prinzipien Lesbarkeit und Tool-Orientierung. Lesbarkeit wird am besten von der block-orientierten
Repräsentation unterstützt, da bis auf Links keine IDs und ID-Referenzen benutzt werden. Jedoch müsste eine graphische Darstellung komplexe Abbildungsregeln definieren,
was der Tool-Orientierung widerspricht. Kanten-Element-Listen sind zwar weniger
leicht lesbar, dafür jedoch sehr flexibel. Da sie auch von anderen Spezifikationen genutzt
werden, erleichtert dies werkzeug- und methodenbezogene Transformationen. Daher
werden EPK-Prozessgraphen in EPML mit Hilfe von Kanten-Element-Listen beschrieben.
4
Prozessgraph-Elemente und deren Beziehungen
In diesem Kapitel wird das EPML-Verständnis eines EPK-Kontrollflusses dargestellt.
Sichten auf den Kontrollfluss werden in Kapitel 6 besprochen. Da EPML auf dem Konzept einer EPK-Schemamenge aufbaut [NR02], ist es möglich, mehrere EPK-Modelle in
einem EPML-File abzuspeichern. Zuerst wird eine Übersicht über die Organisation mehrerer EPK-Modelle und deren modellübergreifende Beziehungen in einem EPML-File
95
behandelt. Danach werden die einzelnen Elemente eines EPK-Modells in ihrer EPMLSyntax vorgestellt.
4.1
Hierarchien von EPK-Modellen
<epml> ist das Wurzelelement eines EPML-Files. Wie alle anderen Elemente kann es
<documentation> und <toolInfo> Kindelemente enthalten. Diese können zusätzliche Daten enthalten wie etwa Kommentare und werkzeugspezifische Informationen. Es wird jedoch empfohlen, lediglich standardisierte Dublin Core Metadata Elemente [DC03] für die Dokumentation eines EPML-Files zu benutzen und nur solche anwendungsspezifischen Daten beizufügen, die sich auf die interne Speicherung von Modellen
in spezifischen Tools beziehen, aber nicht die graphische Präsentation der Modelle beeinflussen. Allgemeine Graphik-Einstellungen könnten mit Hilfe des <graphicsDefault> Elementes vorgenommen werden (siehe Kapitel 5). Das <coordinates>
Element dient der genauen Angabe der Ausrichtung des Koordinatensystems und damit
der Interpretation der Positionsangaben der graphischen EPML-Elemente. Das
@xOrigin Attribut kann die Werte“leftToRight” oder “rightToLeft” annehmen und das
@yOrigin Attribut “topToBottom” oder “bottomToTop”. Es wird empfohlen, stets die
Ausrichtung “leftToRight” und “topToBottom” zu benutzen. Dies ist allgemein üblich.
Dennoch gibt es Ausnahmen wie zum Beispiel MS Visio, dessen Y-Achse von unten
nach oben verläuft. Es wird empfohlen, solche Koordinaten zu transformieren, bevor das
Modell in EPML angelegt wird.
In [NR02] wird eine EPK-Schemamenge als eine Menge hierarchischer EPK-Schemata
definiert. Ein einzelnes EPK-Schema besteht aus einem flachen EPK-Schema, dessen
Funktionen und Prozess-Schnittstellen Hierarchierelationen besitzen können. Eine detaillierte Betrachtung von flachen EPK-Schemata und deren Syntax-Elementen wird im
folgenden Abschnitt vorgenommen. Syntaktisch stellt eine Hierarchierelation ein Paar
von einer Funktion oder einer Prozess-Schnittstelle einerseits und einem EPK-Modell
andererseits dar. Semantisch ist dies als ein Aufruf eines Sub-Prozesses zu verstehen.
<epml> hat außerdem <definitions> Kindelemente, die im Zusammenhang mit
<directory> Elementen erklärt werden. Das <view> Element wird in Kapitel 6
vorgestellt.
In EPML wird eine Hierarchie von Prozessen mit Hilfe von Verzeichnissen organisiert.
Ein <directory> beinhaltet ein @name Attribut, andere Verzeichnisse und/oder
EPK-Modelle. Jede <epc> wird über ein @epcId Attribut identifiziert und hat zudem
ein @name Attribut. Die @epcId kann von Hierarchierelationen in Funktionen und
Prozess-Schnittstellen aus referenziert werden. In einer Hierarchie von EPK-Modellen
können Redundanzen auftreten, wenn eine Funktion oder ein anderes Prozess-Element in
zwei oder mehr Prozessen benutzt wird. In diesem Fall benötigt man eine Stelle, an der
man solche Informationen ablegen kann, um dann im konkreten Prozess darauf zu referenzieren. Dies ist die Funktion des <definitions> Elements. Dieses dient als Container für Kontrollfluss-Elemente, die mehrmals in der Modellhierarchie benutzt werden.
96
4.2
EPK-Modelle in EPML-Syntax
Eine formale Spezifikation der EPK-Syntax und –Semantik geben [NR02] und [Ki03].
In [KNS92] wird das EPK-Konzept eingeführt, um die zeitlichen und logischen Abhängigkeiten in Geschäftsprozessmodellen abzubilden. Elemente der EPK können vom Typ
Funktion (aktive Elemente) symbolisiert durch <function>, vom Typ Ereignis (passive Elemente) repräsentiert von <event> oder vom Konnektor-Typ AND, OR, oder
XOR sein, wobei die Konnektoren entweder Split- oder Join-Operatoren sein müssen.
Sie werden mit den EPML-Elementen <and>, <or> und <xor> beschrieben. Diese
Objekte sind über <arc> Elemente verbunden und stellen den Kontrollfluss dar. Im
Zusammenhang mit den Einsatzerfahrungen mit dem SAP Referenzmodell wurden zusätzlich Prozess-Schnittstellen und hierarchische Funktionen eingeführt [KM94]. Das
<processInterface> wird dazu benutzt, um vom Ende eines Prozesses auf einen
Folgeprozess zu verweisen. Eine hierarchische <function> ermöglicht es, MakroProzesse zu definieren, die auf Subprozesse verweisen. Beide Arten von Relationen
werden mit Hilfe des <toProcess> Elements beschrieben, dessen @linkToEpcId
eine Relation mit einem anderen EPK-Prozess repräsentiert. Ereignisse, Funktionen,
Prozess-Schnittstellen, Konnektoren und Kontrollflusskanten sind die syntaktischen
Elemente einer flachen EPK-Schemamenge [NR02]. Sie alle besitzen ein @id Attribut,
ein <name> Element, ein <description> Element, ein <graphics> Element
(beschrieben in Kapitel 5) und ein <syntaxInfo> Element, das zusätzliche Informationen bezüglich des impliziten Elementtyps enthalten kann. Syntaxinformation dient dem
Design-Prinzip der syntaktischen Richtigkeit und erlaubt eine leichtere Verifikation von
EPK-Syntaxeigenschaften. Für eine Darstellung von impliziten Elementtypen und EPKSyntaxeigenschaften sei auf [MN03a, MN03c] verwiesen.
Manche Kontrollflusselemente haben spezielle Elemente. Möglicherweise werden dieselben Ereignisse, Funktionen und Prozess-Schnittstellen mehrmals in einer Hierarchie
von EPKs verwendet. Um daraus resultierende Redundanzen zu vermeiden, kann das
<reference> Element anstelle des <name> und <description> Elementes benutzt werden. Es referenziert die Definition eines Ereignisses, einer Funktion oder einer
Prozess-Schnittstelle, die zentral den Namen und die Beschreibung abspeichert. Funktionen können zudem eine <unitReference> besitzen. Sie stellt den Verweis auf eine
Sicht dar und wird in Kapitel 6 beschrieben. Kanten müssen in der Lage sein, zwei andere Knontrollflusselemente zu verbinden. Dazu dient das Element <flow>. Es enthält
zwei Attribute, die jeweils auf ein id-Attribut verweisen: @source und @target.
5
Grafik-Information
Graphische Information bezieht sich auf die Präsentation von EPK-Modellen in graphischen Modellierungswerkzeugen. Im Rahmen der Petri Net Markup Language (PNML)
existiert hierzu ein umfassender Vorschlag, welcher weitgehend auch für EPML übernommen werden kann. Ähnlich wie das <graphics> Element der Kontrollflusselemente kann das Toplevel-Element <graphicsDefault> sowohl <fill>, <line>
und <font> Standardeinstellungen definieren, jedoch kein <position> Element.
97
Alle vier Attribute des <position> Elements beziehen sich auf das kleinste Rechteck,
das parallel zu den Achsen um das polygone Symbol eines Objektes herum gezeichnet
werden kann. Die @x und @y Attribute beschreiben den Abstand jener Ecke des Symbols
vom Ursprung des Koordinatensystems, der am nächsten am Ursprung ist. @width und
@height beschreiben die Länge der Kanten des einschließenden Rechteckes. In PNML
wird ein separates Dimension-Element für die Repräsentation dieser Aspekte benutzt.
Kanten können mehrere Positions-Elemente besitzen, die Ankerpunkte des Kantenverlaufes beschreiben, sie haben keine width- und height-Attribute.
Das <fill> Element definiert die Füllfarbe des Innenraums eines Objektes. Kanten
haben keine fill-Elemente. Das @color Attribut muss einen RGB-Wert oder eine vordefinierte Farbe gemäß Cascading Stylesheets 2 (CSS2) [Bo98] enthalten. Um eine kontinuierliche Variation der Füllfarbe darzustellen, kann eine optionale @gradientcolor definiert werden. Die @gradient-rotation setzt die Orientierung des Gradienten auf entweder vertikal, horizontal oder diagonal. Falls eine URI im @image
Attribut aufgeführt wird, werden die anderen Attribute ignoriert. Das <line> Element
definiert die Außenlinie des Objektes. Das @shape Attribut verweist darauf, wie Kanten dargestellt werden: der Wert „line” repräsentiert eine lineare Verbindung der Ankerpunkte in Form eines Polygons; der Wert „curve” steht für eine quadratische BezierKurve. Das <font> Element umfasst @family, @style, @weight, @size und
@decoration Attribute, wie mit CSS2 conform sind. Zusätzlich zu PNML kann eine
Schriftfarbe angegeben werden. @verticalAlign und @horizontalAlign spezifizieren die Ausrichtung des Textes. In PNML entspricht das align-Attribut dem horizontalAlign-Attribut von EPML, und das verticalAlign-Attribut ist über das PNML offsetElement abgedeckt. @rotation bezeichnet die Rotation des Textes im Uhrzeigersinn
des Textes genau wie in PNML auch.
6
Sichten auf Prozesse
Sichtenbildung spielt eine wichtige Rolle für die Analyse und Konzeption von Prozessmodellen [Fr94]. Perspektiven im Allgemeinen haben sich als wertvoll für die Untergliederung der Spezifikation eines komplexen Systems erwiesen [Fi92]. Dieser Ansatz
wurde für EPKs erweitert, um eine personalisierte Präsentation von Prozessmodellen zu
ermöglichen [Be03].
Es gibt eine ganze Reihe von Vorschlägen an relevanten Perspektiven und Sichten für
die Modellierung von Geschäftsprozessen. Die Architektur Integrierter Informationssysteme (ARIS) erweitert die EPK mit einer daten-, funktions-, organisations- und leistungsorientierten Sicht [Sc00]. Das PROMET-Konzept differenziert zwischen Geschäftsdimensionen, wobei explizit Organisation, Daten, Funktionen und Personal genannt werden [Ös95]. Eine tiefgehende Übersicht über die Definitionsmöglichkeiten von
Organisationseinheiten in Workflow-Systemen findet sich in [RM98]. Die Beziehung
zwischen rollenbasierter Zugriffskontrolle (RBAC) und Geschäftsszenarien wird in
[NS02] analysiert und dient der Entwicklung einer Methode zur Ableitung von Rollenhierarchien. Mit speziellem Fokus auf Delegation wird in [AKV03] die Organisations-
98
perspektive in Workflow-Systemen strukturiert, welches in einem Metamodell mit Ressourcen, Organisationseinheiten, Benutzern und Rollen mündet. In [Wh03] und
[BAN03] werden „swim lanes“ und „pools“ als Metapher zur graphischen Strukturierung von mehreren Parteien in einem Geschäftsprozess empfohlen. Neuerdings spielen
WSDL-Beschreibungen [Ch01] von Web Services eine Rolle in Sprachen wie
BPEL4WS als eine neue Kategorie von Ressourcen. Jenseits von Ressourcen wurden
weitere Sichten wie etwa Risiko [BO02] oder Performance-Maßzahlen [IDS03b] vorgeschlagen, um nur einige zu nennen.
Die DAML-S Initiative hat sich das Ziel gesetzt, eine standardisierte GeschäftsprozessOntologie für Web Services zu entwickeln [DA03]. Dies ist eine schwierige Aufgabe,
wenn man sich die Vielfalt der möglichen Perspektiven vor Augen führt. Es gibt Zweifel, ob eine standardisierte Ontologie überhaupt wünschenswert ist, da verschiedene
Domänen und Geschäftssektoren maßgeschneiderte Metamodelle brauchen, die ihrem
Geschäftsmodell am besten entsprechen [KK02]. Diese Argumente haben dazu geführt,
dass EPML von dem Prinzip der Erweiterbarkeit geleitet wird und folglich keine standardisierten Sichten vordefiniert. Das <view> Element dient als Container für Einheiten einer speziellen Sicht und deren Beziehungen. Das <unit> Element beschreibt eine
Einheit innerhalb einer Sicht mit Hilfe einer @unitId und eines @name Attributes. Die
<unitRelation> drückt eine hierarchische Beziehung mit einem @unitRef Attribut und einem @subUnitRef Attribut aus. Die @annotation kann für eine detaillierte Bezeichnung der Relation genutzt werden. Es gibt zudem eine @relationId,
um logisch zwischen verschiedenen Beziehungen zwischen zwei gleichen Elementen zu
unterscheiden. Funktionselemente des Kontrollflusses können eine <unitReference> enthalten. Das @role und das @value Attribut ermöglichen die Spezifikation
von zusätzlichen Informationen bezüglich der Beziehung zwischen einer Funktion und
einer Unit.
7
Ausblick
In diesem Beitrag wurde ein Konzept für eine EPK Markup Language (EPML) vorgestellt. Dieser Ansatz dient dazu, ein Austauschformat für EPK-Modelle bereitzustellen.
Es ist von den Prinzipien Lesbarkeit, Erweiterbarkeit, Tool-Orientierung und Syntaktische Richtigkeit geleitet. In den vorangegangenen Kapiteln wurden auch Best-Practices
anderer graphenorientierten Spezifikationen betrachtet und die Entwurfsentscheidungen
transparent gemacht. Dies beinhaltet eine detaillierte Diskussion der Prozessrepräsentation, der EPK-Prozesselemente und ihren Beziehungen untereinander, graphische Informationen sowie die Betrachtung von Sichten auf ein Geschäftsprozessmodell.
Das EPML-Konzept ist offen für Diskussionen und Anregungen, um innerhalb der EPKCommunity einen Konsens bezüglich der Repräsentation von EPKs in EPML zu erreichen und EPML-Anwendungen zu fördern. Es gibt eine Reihe von Themen, die in der
Zukunft in Angriff genommen werden. Zum ersten werden Transformationsskripte entwickelt werden, die die Nutzung von EPML als Austauschformat ermöglichen werden.
Als zweites wird eine Transformation von EPML nach Scalable Vector Graphics (SVG)
99
[Fe03] die optische Erscheinung von EPML-Modellen standardisieren. Zum dritten
werden XSLT-Skripte [Cl99] eine XML-basierte Syntax-Validierung von EPKModellen ermöglichen [MN03c]. Und zuletzt bedarf es weiterer Forschung im Bereich
Sichten. Methodisch werden hierfür Techniken der Metamodellierung und des Semantic
Web Berücksichtigung finden. Zudem bedarf es weitergehender Untersuchungen, um
spezifische Sichten formal zu spezifizieren. Die Administration von dezentralen, lose
verbundenen Modellen wird dabei ebenfalls eine Rolle spielen. In diesem Zusammenhang kann die Entwicklung von EPML – jenseits ihrer kurzfristigen Ausrichtung als
Austauschformat – als Katalysator für all diese Themen dienen.
Literaturverzeichnis
[AKV03] van der Aalst, W.M.P.; Kumar, A.; Verbeek, H.M.W.: Organizational Modeling in UML
and XML in the Context of Workflow Systems. In: Proceedings of the 2003 ACM Symposium on Applied Computing (SAC), March 9-12, 2003, Melbourne, Florida, USA, S.
603-608.
[AL02] Arenas, M.; Libkin, L.: A normal form for XML documents. In: Proceedings of the 21st
ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems
(PODS’02), June 3-6, 2002, Madison, Wisconsin, USA, S. 85-96.
[AL03] Arenas, M.; Libkin, L.: An Information-Theoretic Approach to Normal Forms for Relational and XML Data. In: Proceedings of the 22nd ACM SIGACT-SIGMOD-SIGART
Symposium on Principles of Database Systems (PODS’03), June 9-12, 2003, San Diego,
California, USA, S. 15-26.
[AN02] ANSI (Hrsg.): ASC X12 Reference Model for XML Design, July 2002.
http://www.x12.org/x12org/comments/X12Reference_Model_For_XML_Design.pdf.
[An03] Andrews, T.; Curbera, F.; Dholakia, H.; Goland, Y.; Klein, J.; Leymann, F.; Liu, K.;
Roller, D.; Smith, D.; Thatte, S.; Trickovic, I.; Weerawarana, S.: Business Process Execution Language for Web Services (BPEL4WS) Version 1.1. BEA, IBM, Microsoft,
SAP, Siebel, 2003.
[Ar02] Arkin, A.: Business Process Modeling Language (BPML). BPMI.org, 2002.
[BAN03] Becker, J.; Algermissen, L.; Niehaves, B.: Prozessmodellierung in eGovernmentProjekten mit der eEPK. In: Nüttgens, M.; Rump, F.J. (Hrsg.): EPK 2003 - Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, Proceedings des 2. GIWorkshop EPK 2003, Bamberg 2003, S. 31-44.
[Be01] Beech, D.; Lawrence, S.; Moloney, M.; Mendelsohn, N.; Thompson, H.S. (Hrsg.): XML
Schema Part 1: Structures. World Wide Web Consortium, Boston, USA, 2001.
http://w3c.org/TR/2001/REC-xmlschema-1-20010502/.
[Be03] Becker, J.; Delfmann, P.; Falk, T.; Knackstedt, R.: Multiperspektivische ereignisgesteuerte Prozessketten. In: Nüttgens, M.; Rump, F.J. (Hrsg.): EPK 2003 - Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, Proceedings des 2. GI-Workshop
EPK 2003, Bamberg 2003, S. 45-60.
[Bi95] Biskup, J.: Achievements of relational database schema design theory revisited. In:
Libkin, L.; Thalheim, B.: Semantics in Databases, LNCS 1358, 1998, S. 29-54.
[Bi03] Billington, J.; Christensen, S.; van Hee, K.E.; Kindler, E.; Kummer, O.; Petrucci, L.;
Post, R.; Stehno, C.; Weber, M.: The Petri Net Markup Language: Concepts, Technology, and Tools. In: van der Aalst, W.M.P.; Best, E. (Hrsg.): Applications and Theory of
Petri Nets 2003, 24th International Conference, ICATPN 2003, Eindhoven, The Netherlands, June 23-27, 2003, Proceedings. LNCS 2679, 2003, S. 483-505.
100
[Bl03]
Black, P.E.: NIST Dictionary of Algorithms and Data Structures, 2003.
http://www.nist.gov/dads/.
[BM01] Biron, P.V.; Malhotra, A. (Hrsg.): XML Schema Part 2: Datatypes. World Wide Web
Consortium, Boston, USA, 2001. http://w3c.org/TR/2001/REC-xmlschema-220010502/.
[Bo98] Bos, B.; Lie, H.W.; Lilley, C.; Jacobs, I. (Hrsg.): Cascading Style Sheets, level 2 – CSS2
Specification. http://w3c.org/TR/CSS2, 1998.
[BO02] Brabänder, E.; Ochs, H.: Analyse und Gestaltung prozessorientierter Risikomanagementsysteme mit Ereignisgesteuerten Prozessketten. In: Nüttgens, M.; Rump, F.J. (Hrsg.):
EPK 2003 - Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, Proceedings des 1. GI-Workshop EPK 2002, Trier 2002, S. 17-34.
[Br00] Bray, T.; Paoli, J.; Sperberg-McQueen, C.M.; Maler, E. (Hrsg.): Extensible Markup
Language (XML) 1.0 (Second Edition). World Wide Web Consortium, Boston, USA,
2000. http://www.w3c.org/TR/2000/REC-xml-20001006/.
[CD99] Clark, J.; DeRose, S.: XML Path Language (XPath) Version 1.0, World Wide Web
Consortium, Boston, USA, 1999. http://www.w3.org/TR/1999/REC-xpath-19991116.
[Ch76] Chen, P.: The Entity-Relationship Model – Towards a Unitied view of Data. In: ACM
Transactions on Database Systems (TODS) 1 (1976), S. 9-36.
[Ch01] Christensen, E.; Curbera, F.; Meredith, G.; Weerawarana, S.: Web Service Description
Language (WSDL) 1.1, World Wide Web Consortium, Boston, USA, 2001.
http://www.w3.org/TR/wsdl.
[Cl99] Clark, J. (Hrsg.): XSL Transformations (XSLT) Version 1.0. World Wide Web Consortium, Boston, USA, 1999. http://w3c.org/TR/1999/REC-xslt-19991116/.
[DA03] The DAML Services Coalition (Hrsg.): DAML-S: Semantic Markup for Web Services.
Whitepaper Version 0.9. http://www.daml.org/services, 2003.
[DC03] Dublin Core Metadata Initiative: Dublin Core Metadata Element Set, Version 1.1: Reference Description. 2003. http://dublincore.org/documents/2003/02/04/dces/.
[Eb87] Ebert, J.: A Versatile Data Structure for Edge-Oriented Graph Algorithms. In: CACM
(30)6, 1987, S. 513-519.
[EM01] Embley, D.W.; Mok, W.Y.: Developing XML documents with guaranteed “good” properties. In: Kunii, H.S.; Jajodia, S.; Sølvberg, A. (Hrsg.): Conceptual Modeling - ER
2001, 20th International Conference on Conceptual Modeling, LNCS 2224, 2001, S. 426
– 441.
[Fe03] Ferraiolo, J.; Jun, F.; Jackson, D. (Hrsg.): Scalable Vector Graphics (SVG) 1.1 Specification. http://www.w3c.org/TR/SVG11, 2003.
[FGW03]Favre, J.-M.; Godfrey, M.; Winter, A.: First International Workshop on Meta-Models
and Schemas for Reverse Engineering - Workshop Description, to appear in: Proceedings Working Conference on Reverse Engineering (WCRE 2003), IEEE Computer Society, 2003.
[Fi92] Finkelstein, A.; Kramer, J.; Nuseibeh, B.; Finkelstein, L.; Goedicke, M.: Viewpoints: A
Framework for Integrating Multiple Perspectives in System Development. In: International Journal of Software Engineering and Knowledge Engineering. 2 (1992) 1, S. 3157.
[Fr94] Frank, U.: Multiperspektivische Unternehmensmodellierung: Theoretischer Hintergrund
und Entwurf einer objektorientierten Entwicklungsumgebung, GMD-Bericht Nr. 225,
München et al. 1994.
[Ga02] Gartner Research: The BPA Market Catches Another Major Updraft. Gartner's Application Development & Maintenance Research Note M-16-8153, 12 June 2002.
[IDS01] IDS Scheer AG (Hrsg.): XML-Export und-Import mit ARIS 5.0, Stand Januar 2001,
Saarbrücken, 2001.
101
[IDS03a] IDS Scheer AG (Hrsg.): Schnittstellen zu ARIS 6.0x / 6.1x / 6.2, Whitepaper Juli 2003,
Saarbrücken.
www.ids-scheer.de/sixcms/media.php/1049/
Uebersicht+Schnittstellen+ARIS+2003-07.pdf.
[IDS03b] IDS Scheer AG (Hrsg.): ARIS Process Performance Manager, Whitepaper 2003, Saarbrücken.
www.ids-scheer.com/sixcms/media.php/
1186/aris_ppm_whitepaper_e_v500.pdf.
[ISO01] Ketels, K.: ISO 15022 XML Design Rules, Technical Specification, 2001.
http://xml.coverpages.org/ISO15022-XMLDesignRulesV23a.pdf.
[Ki03] Kindler, E.: On the semantics of EPCs: A framework for resolving the vicious circle
(Extended Abstract). In: Nüttgens, M.; Rump, F.J. (Hrsg.): EPK 2003 - Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten, Proceedings des 2. GIWorkshop EPK 2003, Bamberg 2003, S. 7-18.
[KK02] Karagiannis, D.; Kühn, H.: Metamodelling Platforms. Invited Paper. In: Bauknecht, K.;
Min Tjoa, A.; Quirchmayer, G. (Hrsg.): Proceedings of the 3rd International Conference
EC-Web 2002 - Dexa 2002, Aix-en-Provence, France, September 2002, LNCS 2455,
Springer-Verlag, p. 182-196.
[KM94] Keller, G.; Meinhardt, S.: SAP R/3-Analyzer: Optimierung von Geschäftsprozessen auf
der Basis des R/3-Referenzmodells, Walldorf, 1994.
[KNS92] Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozeßmodellierung auf der
Grundlage „Ereignisgesteuerter Prozeßketten (EPK)“. In: Scheer, A.-W. (Hrsg.): Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 89, Saarbrücken, 1992.
[Me01] Mertz, D.: Subelement contents versus tag attributes. IBM DeveloperWorks – XML
Zone, Nov 2001. http://www-106.ibm.com/developerworks/xml/library/x-tipsub.html.
[Me03] Mendling, Jan: Event-Driven-Process-Chain-Markup-Language (EPML): Anforderungen, Konzeption und Anwendung eines XML Schemas für Ereignisgesteuerte Prozessketten (EPK). In: Höpfner, H.; Saake, G. (Hrsg.): Proceedings des Studentenprogramms
anlässlich des 10. Symposium "Datenbanksysteme für Business, Technologie und Web",
Magdeburg 2003, S. 48-50.
[Mi99] Milner, R.: Communicating and Mobile Systems: The π-Calculus. Cambridge 1999.
[Mi03] Microsoft (Hrsg.): About the XML for Visio Schema. MSDN Library, 2003.
http://msdn.microsoft.com/library/default.asp?url=/library/enus/devref/HTML/XMLR_XMLBasics_818.asp
[MIS02] Mortgage Bankers Association of America (MISMO) (Hrsg.): MISMO XML Design
Rules
and
Guidelines.
Draft
2.0
RC3,
2002.
http://www.mismo.org/mismo/docs/drftspc/mismoengguidelines.pdf.
[MM03] Mendling, J.; Müller, M.: A Comparison of BPML and BPEL4WS. In: Tolksdorf, R.;
Eckstein, R.: Proceedings der 1. Konferenz "Berliner XML-Tage", Berlin, 2003, S. 305316.
[MN02] Mendling, J.; Nüttgens, M.: Event-Driven-Process-Chain-Markup-Language (EPML):
Anforderungen zur Definition eines XML-Schemas für Ereignisgesteuerte Prozessketten
(EPK). In: Nüttgens, M.; Rump, F. (Hrsg.): EPK 2002 – Geschäftsprozessmanagement
mit Ereignisgesteuerten Prozessketten, Proceedings des GI-Workshop EPK 2002, Trier
2002, S. 87-93.
[MN03a]Mendling, J.; Nüttgens, M.: EPC Modelling based on Implicit Arc Types. In: Godlevsky,
M.; Liddle, S.W.; Mayr, H.C.: Proc. of the 2nd International Conference on Information
Systems Technology and its Applications (ISTA), LNI Vol. P-30, Bonn 2003, S. 131142.
[MN03b] Mendling, J.; Nüttgens, M.: XML-basierte Geschäftsprozessmodellierung. In: Uhr, W.,
Esswein, W.; Schoop, E. (Hrsg.): Wirtschaftsinformatik 2003 / Band II, Heidelberg,
2003, S. 161 -180.
[MN03c] Mendling, J.; Nüttgens, M.: EPC Syntax Validation with XML Schema Languages. In:
Nüttgens, M.; Rump, F.J. (Hrsg.): EPK 2003 - Geschäftsprozessmanagement mit Ereig-
102
nisgesteuerten Prozessketten, Proceedings des 2. GI-Workshop EPK 2003, Bamberg
2003, S. 19-30.
[NR02] Nüttgens, M.; Rump, J.F.: Syntax und Semantik Ereignisgesteuerter Prozessketten
(EPK). In: Desel, J.; Weske, M. (Hrsg.): Promise 2002 - Prozessorientierte Methoden
und Werkzeuge für die Entwicklung von Informationssystemen, Proceedings GIWorkshop und Fachgruppentreffen (Potsdam, Oktober 2002), LNI Vol. P-21, Bonn
2002, S. 64-77.
[NS02] Neumann, G.; Strembeck, M.: A scenario-driven role engineering process for functional
RBAC roles. In: 7th ACM Symposium on Access Control Models and Technologies
(SACMAT 2002), S. 33-42.
[OMG03a]Object Management Group (Hrsg.).: Unified Modeling Language (UML) Specification,
Marc 2003, Version 1.5, 2003.
[OMG03b]Object Management Group (Hrsg.): XML Metadata Interchange (XMI) Specification,
May 2003, Version 2.0, 2003.
[Ös95] Österle, H.: Business Engineering. Prozess- und Systementwicklung, Band 1, Entwurfstechniken, Berlin, 1995.
[RM98] Rosemann, M.; zur Mühlen, M.: Evaluation of Workflow Management Systems - A
Meta Model Approach. In: Australian Journal of Information Systems 6 (1998) 1, S.
103-116.
[Sc00] Scheer, A.-W.: ARIS business process modelling, Berlin et al., 2000.
[SW01] SWIFT (Hrsg.): SWIFTStandards XML Design Rules Version 2.3, Technical Specification, 2001. http://xml.coverpages.org/EBTWG-SWIFTStandards-XML200110.pdf.
[Wf02] Workflow Management Coalition (Hrsg.): Workflow Process Definition Interface –
XML Process Definition Language, Document Number WFMC-TC-1025, October 25,
2002, Version 1.0, Lighthouse Point, USA, 2002.
[Wh03] White, S.A: Business Process Modeling Notation – Working Draft 1.0, Aug. 25, 2003.
BPMI.org, 2003.
[WHB02]Wüstner, E.; Hotzel, T.; Buxmann, P.: Converting Business Documents: A Classification
of Problems and Solutions using XML/XSLT. In: Proceedings of the 4th International
Workshop on Advanced Issues of E-Commerce and Web-based Systems (WECWIS
2002).
[WK02] M. Weber, E. Kindler: The Petri Net Markup Language. In: H. Ehrig, W. Reisig, G.
Rozenberg, and H. Weber (Hrsg.): Petri Net Technology for Communication Based Systems. LNCS 2472, 2002.
[WKR02]Winter, A.; Kullbach, B.; Riediger, V.: An Overview of the GXL Graph Exchange Language. In: Diehl, S. (Hrsg.) Software Visualization - International Seminar Dagstuhl
Castle, LNCS 2269, 2001.
103
104
Beiträge des Arbeitskreises WIWI-KobAs:
Komponentenorientierte
betriebliche Anwendungssysteme
105
106
Vorträge
Vorträge des 4. Workshops
„Modellierung und Spezifikation
von Fachkomponenten“
auf der MobIS 2003
am 10. Oktober 2003 in Bamberg
107
108
Spezifikation von Fachkomponenten mit der
Swiss Re Data Language
Hans Wegener†, Gunnar Auth‡
†
Swiss Re, Mythenquai 50/60, 8022 Zürich, Schweiz, [email protected]
DaimlerChrysler TSS GmbH, Lise-Meitner-Strasse 15, 89081 Ulm,
[email protected]
‡
Deutschland,
Zusammenfassung: Die Swiss Re Data Language ist ein Mittel zur Spezifikation von
Datenschnittstellen auf Basis vereinheitlichter Fachbegriffe. Unsere Erfahrungen mit dem nun
produktiven Release 4 zeigen, dass ein auf formaler Spezifikation basierender Ansatz schnell auf
praktische Grenzen trifft. Zudem muss die Ambiguität von Spezifikationen nach unserer Erfahrung
immer im Verwendungskontext betrachtet werden. Daher schlagen wir vor, Wiederverwendung
von zwischen Fachkomponenten ausgetauschten Daten nicht nur über technische, sondern
zusätzlich über eine Kombination ablauf- und aufbauorganisatorischer Mittel zu verfolgen.
Schlüsselwörter: Referenzdaten, Attributtyp, Temporale Datenbank, Konfigurationsmanagement.
1
Einleitung
Ein wesentliches Problem beim Entwurf von Spezifikationssprachen ist die Balance zwischen
der Beschreibungsfähigkeit auf der einen und Verständlichkeit für den Menschen auf der
anderen Seite: üblicherweise sind in Grossunternehmen Menschen am Entwurf von
Softwaresystemen beteiligt, die keine oder nur geringe Ausbildung im Bereich formaler
Sprachen aufweisen. Dennoch sind sie mehr und mehr gezwungen, diese in ihrer Arbeit zu
verwenden. Die Gebrauchstauglichkeit solcher Mittel wird dadurch zum Erfolgskriterium.
Wir berichten von den Erfahrungen, die wir im Rahmen eines jetzt abgeschlossenen Projekts
mit dem Entwurf einer Spezifikationssprache für Referenzdaten gemacht haben. Ziel ist
darzustellen, welche Techniken aus dem formalen Bereich durch welche informellen ergänzt
werden können, so dass die resultierende Sprache die erforderliche Präzision nicht verliert.
Der Beitrag gliedert sich wie folgt: Zur Schaffung einer einheitlichen begrifflichen Grundlage
werden in Abschnitt 2 zunächst die SDL und ihre Grammatik kurz vorgestellt. Die besondere
Bedeutung des Change Managements und der organisatorischen Einbettung wird in Abschnitt
3 herausgestellt. Anschliessend beschreibt Abschnitt 4 die Anwendung der SDL im Rahmen
der Spezifikation von Fachkomponenten. Einen zentralen Bestandteil des Beitrags bildet die
Darstellung der bisher gemachten Erfahrungen in Abschnitt 5. Der Beitrag endet mit einer
Zusammenfassung und einem Ausblick auf die zukünftige Entwicklung.
2
Die Grammatik der SDL
Die Swiss Re verfolgt einen strukturierten Ansatz zum Management ihrer
Informationsarchitektur, der in [Mart2003] ausführlicher beschrieben ist. Als Grundlage für
das Referenzdatenmanagement wurde die Swiss Re Data Language (SDL) zur einheitlichen
Spezifikation von Daten und Datenschnittstellen entworfen. Innerhalb des
Informationsmanagements ist die SDL das zentrale Mittel zur Beschreibung von
applikationsübergreifenden Referenzdaten. Die Bezeichnung „Data Language“ deutet bereits
109
auf den angestrebten Zweck hin, Syntax und Semantik von Begriffen zu definieren, die bei
der Datenverarbeitung und insbesondere dem Berichtswesen der Swiss Re eine Relevanz
haben. Die SDL wird hier eingesetzt zur Spezifikation von Datenschnittstellen zwischen
Fachapplikationen, genauer: von Attributen in (Kontext-)Entitätstypen.
Die Entwicklung und Betreuung der SDL ist organisatorisch im Referenzdatenmanagement
der Swiss Re angesiedelt. In einem ersten Projekt zur Umsetzung des SDL-Konzepts wurde
damit begonnen, die bisher getrennten Begriffsysteme der Bereiche Finance (FSA-DL) und
Reinsurance (RSA-DL) in der SDL zusammenzuführen. Im Zuge der Integration wurden die
ebenfalls getrennten Applikationen zur Verwaltung von FSA-DL und RSA-DL von einer
neuen SDL-Applikation abgelöst. Die wichtigsten Bestandteile der technischen Lösung sind
ein Repository zur Verwaltung von Glossaren und Taxonomien, sowie eine webbasierte
Administrationskomponente und ein Frontend für die Suche nach Datenstandards. Im
folgenden wird die Grammatik der SDL anhand lexikalischer, syntaktischer und semantischer
Aspekte kurz beschrieben.
2.1
Lexikalische Aspekte
Die Festlegung lexikalischer Aspekte ist in einem global agierenden Unternehmen durchaus
von Wichtigkeit. Da immer noch viele (so auch unsere) Betriebs- und Datenbanksysteme auf
8-Bit-Zeichensätzen beruhen, muss man exakt spezifizieren, wie Sonderzeichen (Umlaute und
Akzentzeichen, Formelzeichen wie Indexierung und Exponentiation, Anführungsstriche)
behandelt werden. Dies betrifft insbesondere Freitext in Begriffsbeschreibungen.
Sprachelemente der SDL basieren auf einer durch die Implementation bedingten Teilmenge
des Zeichensatzes ISO 8859-1. Offizielle Sprache der Swiss Re ist Englisch, wodurch nur
wenige Sonderzeichen unterstützt werden müssen. Für bestimmte Zeichen, die nicht
Bestandteil der ISO 8859-1 sind, wurde spezifiziert, wie dorthin transformiert werden; z.B.
werden die in Microsoft-Word-Dokumenten häufig auftretenden Anführungsstriche „“ nach
"" umgewandelt.
2.2
Syntaktische Aspekte
In der SDL modellieren wir die Terminologie und Taxonomie unserer fachlichen Welt.
Begriffe repräsentieren atomare fachliche Abstraktionen. Homonyme sind möglich. Begriffe
teilen sich auf Repräsentanten fachlicher Wertmengen (Attribute) und die Werte selbst.
Beziehungen etablieren höherwertige Abstraktionen auf Basis von Begriffen, wobei folgende
Beziehungstypen unterstützt werden:
• Begriffsverwandschaft: wird zwischen zwei Begriffen etabliert, wenn diese miteinander
fachlich verwandt sind (z.B. „Currency“ und “Currency Block“). Die Beziehung ist
ungerichtet und wird zum besseren Verständnis des Vokabulars eingesetzt.
• Wertehierarchie: wird zwischen mehreren Werten etabliert und drückt eine Organisation
der Begriffswelt in Unter- und Oberbegriffe aus (z.B. „All Values of Line of Business“
wird aufgeteilt in „Life“ und „Non-Life“, wobei „Non-Life“ Oberbegriff für „Property“,
„Marine“, „Liability“ und andere ist). Über Hierarchien werden insbesondere
Aufzählungstypen (RDBMS, ROLAP) und Dimensionen (MOLAP) modelliert.
• Attributhierarchie: wird aus Attributen gebildet, um ein hierarchisches Datenmodell
aufzubauen, wie es in der Finanzwelt auftaucht („General Ledger“). Zwei ausgewiesene
Dimensionen, der Kontenplan und die so genannten Sichten ([Kontenplan-]Varianten)
stellen die Grundstruktur her. Aus diesen wird in Form von Tripelgruppen für jede
110
auftretende Konto-Sicht-Kombination modelliert, welche finanziellen Fakten für eine
Sicht (z.B. Halbjahresbericht, Abschlussbericht) zu berichten sind.
Die durch Werthierarchien hergestellten Artefakte werden von uns aufgrund ihrer Bedeutung
für Referenzdaten als Referenzbäume bezeichnet. Attributhierarchien werden wegen ihrer
spezialisierten Verwendung Kundenbäume genannt.
Die SDL beschreibt anhand von Begriffen Eigenschaften der Schnittstellenebene. Im
Datenaustausch zwischen Applikationen werden Repräsentationen, so genannte Codes für die
Konstituenten eines Fakts verwendet. Kontexte werden verwendet, um Begriffe zu ihren
Codes zuzuordnen. Zum Beispiel ist in unserem Währungs- und Deviseninformationssystem
der Begriff „Swiss Franc“ durch die Zahl „1000“ repräsentiert, während die ISO-4217 die
Zeichenkette „CHF“ wählt.
Kontexte werden auch für die Definition von Synonymen verwendet. Für jeden Begriff kann
in einem Kontext ein so genannter Alias vergeben werden, z.B. „Branche“ für „Line of
Business“. Bei der Suche im SDL Tool wird, wenn ein Kontext selektiert wurde (vgl. Bild 1),
zusätzlich zum eigentlichen Begriffsnamen auch der Alias zur Trefferermittlung beigezogen.
Die syntaktischen Einschränkungen wollen wir hier nicht in ihrer Gesamtheit aufführen,
sondern nur die wichtigsten nennen:
• Repräsentant eines Referenzbaums ist ein Attribut, alle Knoten inklusive der Wurzel sind
Werte.
• Ein Attribut ist maximal einem Referenzbaum zugehörig, Werte können in mehreren
Referenzbäumen auftreten.
• Der gleiche Begriff darf nur einmal in einem Referenzbaum auftreten.
• Referenz- und Kundenbäume sind zyklenfrei.
• Innerhalb eines Kontexts sind die Codes der Begriffe in Bezug auf die sie enthaltenden
Referenzbäume eindeutig.
• Ein Kundenbaum darf nur Referenzbäume enthalten, in denen sämtliche Begriffe im
Kontext, mit dem der Kundenbaum assoziiert ist, codiert sind.
Wir unterscheiden zwischen harten („Fehler“) und weichen („Warnung“) Einschränkungen.
Letztere können vom Administrator überschrieben werden.
2.3
Semantische Aspekte
Die Definition legt die dem Begriff zu Grunde liegende Semantik fest, die Beschreibung fügt
informelle Erläuterungen an, wie etwa Einsatzbeispiele. Die Semantik des Begriffs ist
dadurch aber noch nicht unbedingt kontextinsensitiv festlegbar. Beispielsweise ist die
Interpretation der Definition eines Kontos abhängig von den verwendeten
Rechnungslegungsgrundsätzen (z.B. Swiss GAAP und US GAAP). Hier helfen Kommentare,
welche die kontextsensitiven Bestandteile der fachlichen Interpretation eines Begriffs
enthalten, während die Definition allgemeingültig formuliert ist. Kommentartypen, denen ein
Kommentar immer eindeutig zugeordnet ist, identifizieren den Interpretationskontext.
Werden Werte zusammengefasst, so beschreibt diese Menge eine fachlich bedingte Gruppe,
die in der Realität auftritt. Es handelt sich um Aufzählungstypen, deren Handhabung durch
die Form des Referenzbaums bestimmt wird. Die natürliche Ordnung orientiert sich an der
Hierarchie des Baums. Die Interpretation in analytischen Systemen, insbesondere
multidimensionalen Datenbanken, folgt dieser (Dimensions-)Hierarchie. Durch die Struktur
111
des Baums wird ausgedrückt, welche Fakten wie aggregiert werden. Fakten eines
Unterbegriffs werden entlang der Relation aggregiert und so mit dem Oberbegriff assoziiert.
3
Change-Management und die SDL
Im Entwurf von SDL R4 spielte das Change-Management eine zentrale Rolle. Jedes Objekt in
unserem Repository („SDL Tool“) erhält eine global eindeutige Identifikationsnummer (SDLID), die sich während des gesamten Lebenszyklus’ nicht ändert. Sowohl Fachapplikationen
als auch Menschen greifen auf das Repository zu (vgl. Bild 1), aber die SDL-ID ist (wegen
ihrer Eindeutigkeit) vor allem für die Applikationen von Bedeutung.
Bild 1: Der Inhalt des SDL Repositories ist im wesentlichen über zwei Modelle zugänglich; temporale Selektion
(hier unter „Validity“ angegeben) wird vor allem von Fachbereichsvertretern genutzt; Applikationen nutzen sie
ebenfalls, greifen aber zuweilen auch (über die nicht dargestellten Systemschnittstellen) auf die an
Schnappschüssen orientierte Selektion zurück.
3.1
Objektgültigkeit und Objektversion bei Konfigurationsverzweigung
Das Versionenmodell verdient eine Erläuterung; es ist eine Mischung aus temporaler und
schnappschussbasierter Handhabung. Die Gültigkeitsperiode eines Objekts wird neben der
Versionsnummer zur Ermittlung der aktuell gültigen Version eines Objekts hinzugezogen,
weil aufgrund von Korrekturen, Vorausarbeit etc. das Objekt mit der höchsten
112
Versionsnummer nicht automatisch das aktuell gültige ist (vgl. Abschnitt 3). Die aktuell
gültige Objektversion ist:
• publiziert,
• hat ihren Gültigkeitsbeginn heute oder in der Vergangenheit und
• wenn es mehrere davon gibt, die höchste Versionsnummer, aber
• wenn ihr Gültigkeitsende in der Vergangenheit liegt, gibt es keine gültige Version.
Diese scheinbar umständliche Logik erklärt sich aus den konfligierenden Bedürfnissen von
Fachbereich und IT. Aus Sicht der Fachabteilungen ist Zeit das wesentliche Kriterium für
Selektion von Begriffs- und Baumversionen, da sich die geschäftlichen Abläufe − für ein
Finanzserviceunternehmen nicht weiter verwunderlich − vor allem nach den Zeitpunkten von
Transaktionen ausrichten. Das hat allerdings den unangenehmen Seiteneffekt, dass die
Selektionsergebnisse zeitlich variieren. Um das im Umgang mit Referenzdaten zu vermeiden,
bevorzugt die IT die schnappschussbasierte Variante. Ein Konflikt tritt auf, wenn konsekutive
Versionen von Repositoryobjekten nicht konsekutiv in der Zeit geordnet sind.
Dies passiert relativ häufig beim Kontenplan (vgl. Bild 2). Konten wie „Accrued interest and
rent“ oder „Real estate held for sale“ sind im Referenzbaum „Account“ enthalten. Versionen
von Referenzbäumen und Begriffen können unabhängig voneinander publiziert werden.
Gängige Praxis ist z.B., dass neue Konten geöffnet und alte geschlossen oder in der Semantik
verändert werden (vgl. die sich ständig verändernden Rechnungslegungsgrundsätze). Dadurch
wird nicht nur das Modell der gedachten Zukunft verändert (d.h. zukünftig gültige Versionen
publiziert), sondern durchaus auch die Gegenwart (d.h. existierende gültige Versionen durch
Publikation einer neuen überschrieben). Es kann also durchaus vorkommen, dass Version 1
und 3 heute gültig wären, Version 2 und 4 aber erst nächstes Jahr.
Version
V4
V3
Published On
Valid To
Valid From
V2
V1
Indefinitely
Time
V1
V1
V3
Bild 2: Veranschaulichung der Definition von „gültige Objektversion“. Zu den vier dargestellten Zeitpunkten ist
die jeweils am unteren Rand bezeichnete Version gültig. Zum letzten Zeitpunkt ist keine Version gültig, weil
Version 4 Version 1 maskiert; sie ist nicht mehr gültig, war aber in der Vergangenheit gültig.
113
Offensichtlich werden durch diese Modellierung implizit mehrere Konfigurationszweige
verwaltet, weil das Werkzeug dazu keine entsprechende Abstraktion anbietet (zu den
Gründen, warum das nicht so ist siehe Abschnitt 3.1). Ein Ausweg ist, Zeit und Version in der
Bewertung der Gültigkeitsfrage zusammenzulegen, weil Zeit auch bei der Selektion eine
dominante Rolle spielt. Ein Konfigurationszweig umfasst die Summe aller während einer
gewählten Periode gültigen Repositoryobjekte.
3.2
Konsistenzsicherung im Rahmen des Change-Management
Das SDL Tool unterstützt zur Konsistenzsicherung bei Veränderungen einen bestimmten
Workflow. Jede neue Version eines Objekts wird zunächst modelliert und dann zur fachlichen
Prüfung eingereicht. Vor der Prüfung nimmt das Repository eine Konsistenzanalyse vor, die
syntaktische Fehler und Warnungen (vgl. Abschnitt 2.2) erfasst. Nachdem diese bereinigt
bzw. explizit überstimmt worden sind, prüft ein anderer Administrator („Vier-AugenPrinzip“) die Änderung semantisch, d.h. nach fachlichen Kriterien. Hier werden insbesondere
Doppelspurigkeiten und Widersprüchlichkeiten abgefangen, die sich einer technischen
Analyse entziehen, und es kann noch einmal geprüft werden, ob die überstimmten
Repositorywarnungen tatsächlich fachlicher Notwendigkeit entsprechen (sie werden vor der
Publikation erneut angezeigt).
Diese doppelte Konsistenzsicherung hat einerseits den Zweck, die Definition der SDL zu
entlasten (weniger Abstraktionen und Konsistenzregeln). Andererseits soll die Syntax nicht
ohne weiteres so weit „abgeschwächt“ werden, dass jeder Administrator modellieren kann,
was ihm bzw. ihr beliebt.
Tatsächlich gibt es z.B. Unterschiede in der Behandlung ungültig gewordener Begriffe.
Während die Finanzabteilung (aus Gründen der Darstellung des Geschichtsverlaufs) selbige
im Referenzbaum belässt, ist es im Bereich Reinsurance üblich, eine neue Baumversion
anzulegen, in welcher der ungültige Begriff nicht mehr auftaucht. Da sich beide Bereiche
gewisse Attribute (d.h. Referenzbäume) teilen, ist es unabdingbar, dass die Abstimmung im
Rahmen eines Geschäftsprozesses abläuft, weil Technik diese Komplexität nur zu sehr hohen
Kosten abzubilden vermag.
4
Spezifikation von Fachkomponenten mit der SDL
Folgende Aspekte der (Daten-)Schnittstelle einer Fachkomponente können durch einfachen
Verweis auf die SDL hinreichend festgelegt werden:
• Fachliche Bedeutung: durch die Definition, Beschreibung und Kommentare eines Begriffs
wird die fachliche Semantik eines Werts (zum Teil kontextsensitiv) angegeben. Unsere
Finanzabteilung publiziert bereits seit längerem ein Glossar auf Basis der SDL, das
weltweit als fachliche Grundlage für Daten liefernde Systeme dient.
• Validierungsregeln: durch den Aufbau eines Attributs bzw. eines Referenzbaums wird
implizit formuliert, welche Werte eine Datenschnittstelle ablehnen kann bzw. annehmen
muss. Der Operational Data Store im Geschäftsbereich Property & Casualty arbeitet
bereits heute nach diesem Prinzip. Weiterhin wird über die Gültigkeitsperiode ersichtlich,
welche Fakten zu welchem Zeitpunkt geladen werden können bzw. als ungültig abgelehnt
werden müssen. So ist es beispielsweise nicht mehr möglich, Neugeschäft in der Währung
„German Mark“ zu buchen, wohl aber Altgeschäft.
114
•
Aggregationsregeln: alle Applikationen, die als „SDL-compliant“ bezeichnet werden,
aggregieren Dimensionsdaten in gleichförmiger Weise, nämlich entlang der Taxonomie
des Referenzbaums.
• Repräsentation: mittels Kontexten entkoppelt man die fachliche Ebene (den Begriff) von
der technischen (dem Code). Der Kontextcode eines Werts kann eindeutig mit selbigem
assoziiert werden, wenn bekannt ist, welches Codesystem die liefernde Komponente
verwendet.
• Change-Management: durch Angabe der Wahl des Selektionsmechanismus’ für
Objektversionen wird auch der Umgang mit Veränderungen vollständig oder teilweise
festgelegt.
Wiederverwendung von Datenstandards wird mit der SDL also auf verschiedenen Ebenen
ermöglicht bzw. vereinfacht (vgl. [Krue1992]):
• Abstraktion: die auf fachsprachlicher Ebene vorhandene Assoziation von Attributen mit
Wertmengen wird mit Referenzbäumen formalisiert und damit technisch handhabbar
gemacht. Über Kontexte wird die technische Repräsentation von der fachsprachlichen
Seite der Begriffe entkoppelt.
• Selektion: das SDL Tool ermöglicht die flexible und effiziente Suche nach vorhandenen
Daten(typ)standards und ein präzises Verständnis ihrer fachlichen Bedeutung.
• Integration: die Bereitstellung temporaler und schnappschussbasierter Behandlung von
Objektversionen ermöglicht es Eigentümern von Komponenten, sich schnell und eindeutig
auf die Modalitäten des Umgangs mit Veränderungen an der Datenschnittstelle zu einigen.
• Spezialisierung: geschieht im Bereich der Werte durch Aufbau von Taxonomien.
Die SDL deckt selbstverständlich nur Attributtypen ab, wenn man von den Kundenbäumen
absieht; Entitätstypen hingegen stehen nicht im Fokus. Wiederverwendung ist hier
Gegenstand anderer, semiformeller Massnahmen, vgl. Abschnitt 6.
In der Swiss Re sind zurzeit Untersuchungen im Gange sind, um die Möglichkeit der
Spezifikation weiterer Abbildungsregeln im Rahmen des Datenaustauschs zu klären. Da die
Abtrennung zur Funktionalität klassischer ETL-Tools allerdings schwierig ist, haben wir noch
keinen Entwurfsentscheid getroffen.
Zur Veranschaulichung werden im folgenden zwei kurze Beispiele für die Spezifikation von
Datenschnittstellen mit der SDL beschrieben
4.1
Beispiele
Die Analyseapplikation „Group Performance Management“ hat eine Datenschnittstelle
beschrieben, die eine (aus etwa 20 Entitätstypen gebildete) Kollektion von 12 Dimensionen
und einer Masszahl (sowie zwei Hilfsattributen) umfasst. Diese können grundsätzlich ohne
Angabe ihrer konkreten Werte genannt werden. Allerdings sind bei dieser Applikation alle
Werte unterhalb „Life“ aus dem Referenzbaum „Line of Business“ ausgeschlossen, genauso
wie bestimmte Werte im Bereich „Non-Life“. Diese müssen nur aufgezählt werden.
Die Analyseapplikation „Technical Steering Values“ hat eine Datenschnittstelle beschrieben,
die 12 Attribute, 3 Masszahlen und 2 Daten umfasst. Als Repräsentation werden die Codes
der RSA-DL gewählt. Auch hier wird durch den Verweis auf definierte Datenstandards und
Repräsentationsformen der Aufwand für die Spezifikation signifikant reduziert.
115
Beide Applikationen basieren auf Schnappschüssen der Referenzdaten; Daten liefernde
Applikationen müssen sich entweder auf diese einstellen oder ihre Daten vorher entsprechend
transformieren.
5
Erfahrungen
Die hier beschriebenen Erfahrungen beziehen sich auf die Periode von Februar 2002 bis
September 2003. Während dieses Zeitraums wurde in der Swiss Re bereits das bestehende
Werkzeug SDL R3 betrieben und als Grundlage für den Entwurf von SDL R4 genutzt.
Letzteres ist seit Juni 2003 im produktiven Einsatz und wird global genutzt. Insgesamt drei
Administratoren in den Vereinigten Staaten und sechs in der Schweiz verwalten Daten für das
Corporate Center und den Geschäftsbereich Property & Casualty.
5.1
Zur Homonymproblematik: Kontextsensitivität der Begriffsintension
Das Auftreten von Homonymen wurde von uns in früheren Entwürfen von SDL R4 verboten
[Wege2003]. Um verschiedenen Vokabularen Rechnung zu tragen, wurden sie in disjunkte
Namensräume unterteilt. Dies stellte sich als nicht machbar heraus. So treten im Kontenplan
äusserst häufig Namensdubletten (wie etwa „Other Assets“) auf. Die Semantik eines jeden
solchen Begriffs ergibt sich erst aus seiner Position in der Hierarchie. Auf die
Vergegenständlichung dieses Zusammenhangs in der Grammatik der SDL wurde aus
Komplexitätsgründen verzichtet, gleichfalls kam eine Umbenennung („Other Assets 1..n“)
nicht in Frage. Zudem werden Konten mit hierarchisch aufgebauten Codes versehen, wodurch
für den Menschen wieder akzeptable Eindeutigkeit hergestellt wird.
Diese Erfahrung wirft die Frage auf, was ausser dem Namen eines Fachbegriffs als Merkmal
für die eindeutige Bestimmung der Intension angegeben werden muss und welche Mittel
akzeptabel sind. Üblicherweise geht eine formale Spezifikation davon aus, dass das darin
verwendete Glossar homonymfrei ist. Falls das nicht so ist, muss noch der Zusammenhang
angegeben werden, um Eindeutigkeit herzustellen. Bei uns wird die Intension über mehrere
Aspekte näher bestimmt, nämlich die Definition, die Beschreibung, die Lage des Begriffs im
Referenzbaum sowie allfällig vorhandene Kommentare. (Man beachte, dass ein Begriff auch
in mehreren Referenzbäumen auftreten kann.) Die fachsprachliche Realität stellt sich also als
relativ komplex dar (vgl. Bild 3).
Eine grosse Herausforderung bei der Bereitstellung von Modellierungsmitteln zur formalen
Spezifikation von Komponenten ist die Identifikation der angemessen Zahl und Granularität.
Eine zu nahe an der fachsprachlichen Realität orientierte Welt wird wegen ihrer Komplexität
wenig oder keine Benutzerakzeptanz finden, während eine zu realitätsfremde Welt vielleicht
noch verwendet werden wird, aber keine Aussagen von Interesse zu treffen vermag. Nach
unserer Erfahrung sind bei der Güterabwägung vor allem folgende (bei uns beobachtbare)
Effekte nutzbar:
1. Es ist zumeist klar, in welchem Fachgebiet man sich bewegt. Je kleiner die fachlichen
Überschneidungen zwischen den Gebieten, desto geringer ist die Bedeutung von
Homonymen.
2. Innerhalb eines Verwendungskontexts treten Homonyme seltener bei Attributen als bei
Werten auf. Von 81 Attributen tritt bei uns nur ein einziges doppelt auf (1.2%), und das
nur auf Grund eines Missverständnisses während der Datenmigration. Von 4089 Werten
sind allerdings 357 Dubletten bzw. Tripletts zu vermelden (8.7%).
116
3. Innerhalb eines Fachgebiets ist so viel (teilweise redundante) Information vorhanden, dass
Homonyme keine grossen Ambiguitäten erzeugen.
Diese Effekte erlauben es uns, bei den Abstraktionen der SDL auf einen Teil der
formalsprachlichen Präzision zu verzichten, ohne dass dadurch die Fähigkeit zum Verstehen
der fachlichen Bedeutung signifikant leidet.
Bild 3: Die kontextsensitiven Aspekte von Fachbegriffen werden in der SDL über die hier abgebildete Sicht
angezeigt: Definition, Beschreibung (bei diesem Begriff nicht vorhanden), Kommentare, Verortung in der bzw.
den Referenzstruktur(en) und den aus Platzgründen nicht gezeigten Kundenstruktur(en).
117
5.2
Temporale und versionenbasierte Welt
Die Modellierung eines leistungsfähigen, aber verständlichen Versionskonzepts erwies sich
als enorm schwierig. Die Tatsache, dass sich verschiedene Artefakte (Begriffe, Bäume,
Kontexte) unabhängig voneinander ändern können und zudem noch die Gültigkeitszeiträume
zur Berechnung der aktuell zu verwendenden Version hinzugezogen werden müssen, stellt
grosse Anforderungen an die Fachvertreter. Wir mussten diverse Vereinfachungen
vornehmen, die im Interesse der Allgemeingültigkeit des Konzepts als bedauernswert zu
beurteilen sind. Wir mussten feststellen, dass die Einfachheit des Entwurfs eine wesentliche
Rolle für die Kundenakzeptanz spielt, auch wenn die formale Eindeutigkeit darunter leidet.
Heute wird die implizite Erstellung von Konfigurationen (A bezieht sich auf die aktuell
gültige Version von B) der expliziten (A bezieht sich auf Version 17 von B) vorgezogen.
Seiteneffekte sind so schlechter zu erkennen; gleichfalls leidet die Fähigkeit zur
Konsistenzanalyse.
Diverse Gespräche mit Applikationsvertretern zeigten uns, dass zeitlich äquidistante (z.B.
quartalsweise) Publikation von Artefakten den Change-Prozess in der IT vereinfacht, aber in
den Fachgebieten trotzdem nicht zu Konflikten führt. Teilweise ist es dort (z.B. im
Finanzbereich) ohnehin schon aus anderen Gründen gängige Praxis. Diese idiomatische
Lösung funktioniert relativ zuverlässig, ohne dass der Sachverhalt vergegenständlicht werden
müsste.
Es wurde von uns erwogen, den Entwurf der SDL radikal zu vereinfachen, um die
Verständlichkeit zu erhöhen, aus Akzeptanzgründen aber nicht umgesetzt. Gleichfalls wurde
erwogen, Verzweigungen der Versionshistorie anzubieten, um von der etwas eigenartigen
Modellierung von Varianten in Kundenbäumen wegzukommen. Ebenfalls dachten wir über
ein bitemporales Datenmodell nach [Snod1999]. Dies wurde aber sowohl von den
Fachabteilungen (aus Komplexitätsgründen) als auch von den Geldgebern (wegen des
Projektrisikos) abgelehnt.
6
Zusammenfassung und Ausblick
Schon die verhältnismässig einfache SDL entwickelte zusammen mit dem Versionskonzept
eine beachtliche Komplexität und wir gelangten an die Grenzen des Akzeptablen. Die
Modellierung einer Fachsprache mit wenigen Ausdrucksmitteln gestaltete sich als der zu
erwartende Kompromiss. Wir glauben, dass er uns gut gelungen ist. Insbesondere nutzen wir
die menschliche Fähigkeit zum intelligenten Umgang mit Homonymen und erzielen so eine
Entlastung der Konzeptwelt der SDL, ohne zu stark an Klarheit einzubüssen. Unsere
Erfahrung zeigt auch, dass temporalen Aspekten von Fachbegriffen – vielleicht auch bedingt
durch unsere Betonung der ökonomisch-analytischen Welt – grosse praktische Relevanz
zukommt.
Als Diskussionsbeitrag stellen wir die Frage, wie weit die “vollständige, widerspruchsfreie
und eindeutige Beschreibung“ [Turo2002] von Fachkomponenten auf Basis von
Fachterminologie praktisch beherrschbar ist, und inwieweit kontextinsensitive Eindeutigkeit
überhaupt nötig ist. Da im Memorandum des GI AK 5.10.3 (unter anderem) auf
Wiederverwendung abgezielt wird, möchten wir die Frage aufwerfen, ob allein technische
Mittel zur Realisierung von Wiederverwendungspotenzial hinreichend bzw. nötig sind.
Insbesondere stellen wir diese Frage, weil
1. es beinahe unmöglich ist, sich Kosten- und Zeitdruck zu entziehen und Altlasten selten zu
eliminieren sind,
118
2. allerhöchste formelle Genauigkeit in einer mit vielen Ambiguitäten behafteten
Fach(sprach)welt nicht der entscheidende Erfolgsfaktor (sondern manchmal sogar
hinderlich) ist und
3. unsere Erfahrungen mit einer repositorybasierten Lösung die praktischen
Verständlichkeits- bzw. Komplexitätsgrenzen deutlich aufzeigen.
Bei Swiss Re konzentrieren wir uns daher insbesondere bei der Wiederverwendung von
Entitätstypen verstärkt auf (semiformelle) Ansätze im methodischen Bereich und verwenden
dazu (vgl. [Mart2003]):
1. ein architekturelles Rahmenwerk als Richtschnur zur Datenmodellierung,
2. ein enges organisatorisches Netz als Projekthilfe und -korrektiv und
3. technische Massnahmen zur Abbildung existierender Lösungen auf die SDL (vgl.
Abschnitt 4).
Wir stehen dabei erst am Anfang, können aber sagen, dass durch die höhere Flexibilität die
Akzeptanz trotz geringerer formaler Strenge höher ist; damit, so hoffen wir, wird der
Wiederverwendungsgedanke auf fruchtbaren Boden fallen.
7
Literatur
[Turo2002]
Turowski,
K.:
Vereinheitlichte
Spezifikation
von
Fachkomponenten.
http://www.fachkomponenten.de, Abruf am 2003-05-15.
[Krue1992] Krueger, C. W.: In: Software Reuse. ACM Computing Surveys, 24 (1992), S. 132-183. 1992
[Mart2003] Marti, R.: Information Integration in a Global Enterprise. Some Experiences from a Financial
Services Company. In: Weikum, G., Schöning, H., Rahm, E. (Hrsg.): Tagungsband der BTW
2003, http://www.btw2003.de, Abruf am 2003-05-15.
[Wege2002] Wegener, H., Auth, G.: Die Swiss Re Data Language – Erfahrungen mit Terminologiemanagement
im Rahmen des Data Warehousing. In: von Maur, E., Winter, R. (Hrsg.): Tagungsband der DW
2002, Heidelberg 2002.
[Snod1999] Snodgrass, R.: Developing Time-Oriented Database Applications in SQL. San Francisco 1999.
119
120
Entwicklung eines Metamodells für die
„Vereinheitlichte Spezifikation von
Fachkomponenten“
Peter Fettke, Peter Loos
Johannes Gutenberg-Universität Mainz, Lehrstuhl für Wirtschaftsinformatik und BWL, ISYM - Information Systems & Management, D-55099 Mainz, Germany, Tel.: +49 6131 39-22018, Fax:
-22185, E-Mail: {fettke|loos}@isym.bwl.uni-mainz.de, WWW: http://www.isym.bwl.uni-mainz.de
Zusammenfassung. Metamodelle sind allgemein bekannte Instrumente zur Systemgestaltung. In
diesem Beitrag wird ein Metamodell für die „Vereinheitlichte Spezifikation von Fachkomponenten“ der Arbeitsgruppe 5.10.3 „Komponentenorientierte betriebliche Anwendungssysteme“ der
Gesellschaft für Informatik (Memorandum) entwickelt. Das mit Hilfe des Entity-RelationshipModells formulierte Metamodell enthält weit mehr als 50 Konstrukte (Entitäts- und Beziehungstypen). Im Metamodell können verschiedene Beziehungen zwischen den Spezifikationsebenen des
Memorandums aufgezeigt werden. Ebenso ist die Identifikation von Interpretationsspielräumen
möglich. In künftigen Arbeiten können das vorgestellte Metamodell verfeinert sowie die unterbreiteten Gestaltungsspielräume zur Weiterentwicklung des Memorandums aufgegriffen werden.
Schlüsselworte: Komponenten, Metaisierung, Komponenten-Repositorium, Lehre, Modellierung
1
Ausgangssituation und Motivation
Die komponentenbasierte Softwareentwicklung verspricht die Effektivität und Effizienz der
Systementwicklung zu verbessern [Same97; Szyp02; Grif98; Turo01]. Während notwendige
Technologien für eine komponentenbasierte Entwicklung weitgehend verfügbar sind, bspw.
Enterprise Java Beans von Sun oder .NET von Microsoft, besteht ein Entwicklungsbedarf bei
der Spezifikation von Fachkomponenten. Einen Beitrag zur Überwindung dieser Problematik
leistet das von der Arbeitsgruppe 5.10.3 „Komponentenorientierte betriebliche Anwendungssysteme“ der Gesellschaft für Informatik entwickelte Memorandum „Vereinheitlichte Spezifikation von Fachkomponenten“ [Acke+02] (siehe Abschnitt 2.1, das Wort „Memorandum“
bezeichnet im Folgenden diesen Spezifikationsvorschlag).
Das Memorandum schlägt eine Spezifikation von Fachkomponenten auf unterschiedlichen
Spezifikationsebenen vor, wobei unterschiedliche Notationen für die einzelnen Spezifikationsebenen eingeführt werden (bspw. Interface Definition Language (IDL) der Object Management Group (OMG), Object Constraint Language (OCL), Tabellenform). Auf den ersten
Blick lässt die gewählte aspektorientierte Spezifikation einer Fachkomponente vermuten, dass
die einzelnen Spezifikationsebenen unabhängig voneinander sind. Indes zeigt eine detailliertere Analyse, dass zwischen den einzelnen Konstrukten unterschiedlicher Spezifikationsebenen Abhängigkeiten bestehen können. Beispiele für Abhängigkeiten sind: 1. Auf der Verhaltensebene können nur diejenigen Dienste spezifiziert werden, die auf der Schnittstellenebene
bereits definiert worden sind. 2. Die Dienste, die auf der Schnittstellenebene eingeführt worden sind, werden Aufgaben zugeordnet, die auf der Aufgabenebene definiert werden. 3. Gene-
rell sollen auf der Terminologieebene sämtliche Begriffe definiert werden, die auf den anderen Spezifikationsebenen verwendet werden.
Die genannten Beispiele zeigen, dass die vom Memorandum eingeführten Spezifikationsebenen einer Fachkomponente nicht vollständig unabhängig voneinander sind, sondern gegenseitige Abhängigkeiten untereinander aufweisen. Aus Sicht der Autoren leidet hierdurch einerseits die Verständlichkeit für die einzelnen Spezifikationsebenen einer Fachkomponente. Andererseits, kann dies dazu führen, dass die Spezifikation einer Fachkomponente Inkonsistenzen, Redundanzen bzw. Unvollständigkeiten aufweist, die bei separater Betrachtung einzelner
Spezifikationsebenen nicht ersichtlich werden, sondern erst bei einer ebenenübergreifenden
Analyse aufgedeckt werden können.
Um Klarheit über diese Sachverhalte zu schaffen, halten die Autoren es für sinnvoll, ein einheitliches und integriertes Metamodell für die im Memorandum vorgeschlagenen Notationen
zu entwickeln (vgl. die Argumentation von [SüEb97, 1f.] im Kontext der Booch-Methode). In
einem Metamodell können die einzelnen Konstrukte der verwendeten Notationen und deren
Zusammenhang verdeutlicht werden. Die verschiedenen Notationen sollten in einem Metamodell integriert werden, sodass vorhandene Abhängigkeiten und Beziehungen zwischen den
Konstrukten der verschiedenen Notationen expliziert werden.
1. Besseres
Verständnis seitens
der Benutzer
2. Überprüfung der
Konstrukte
Metamodell der
"Vereinheitlichten
Spezifikation von
Fachkomponenten"
4. Grundlage für
Implementierung
eines Werkzeuges
zur Verwaltung von
Spezifikationen
3. Ausgangspunkt für
Vergleich alternativer
Ansätze zur Spezifikation
von (Fach-)Komponenten
Bild 1: Nutzenpotenziale des Metamodells
Aus einer allgemeinen Perspektive eröffnet ein integriertes Metamodell für die einzelnen Notationen des Memorandums verschiedene Nutzenpotenziale (vgl. Bild 1):
1. Besseres Verständnis für die verschiedenen Konstrukte der Notationen des Memorandums: Ein Metamodell kann die Kommunikation zwischen Nutzern des Memorandums unterstützen, indem sämtliche Konstrukte der Spezifikationsrahmens und ihrer
Beziehungen expliziert werden. Hierdurch kann ebenso die Lehrbarkeit des Spezifikationsansatzes in Theorie und Praxis erleichtert werden. Durch Verweis auf bestimmte
Konstrukte des Metamodells, kann ferner die Weiterentwicklung des Memorandums
und seiner Spezifikationsaspekte systematisch unterstützt werden.
2. Überprüfung der Konstrukte der Notationen des Memorandums: Durch die Erstellung
eines Metamodells können Zusammenhänge zwischen verschiedenen Konstrukten der
verschiedenen Notationen aufgedeckt werden. Hierdurch wird es möglich, Konsistenz
und Widerspruchsfreiheit zu überprüfen. Ebenso können Abhängigkeiten und Zusammenhänge zwischen Konstrukten verschiedener Ebenen aufgedeckt werden.
3. Ausgangspunkt für Vergleich alternativer Ansätze zur Spezifikation von
(Fach-)Komponenten: Neben dem Memorandum existieren alternative Ansätze zur
Spezifikation von (Fach-)Komponenten [DSWi98; BJPW99; Fisc00; Han99]. Auf der
Grundlage der Metamodelle der verschiedenen Ansätze wird es möglich, Ähnlichkeiten und Gemeinsamkeiten zwischen den Ansätzen systematisch darzustellen und zu
untersuchen.
4. Grundlage für die Implementierung eines Werkzeuges zur Verwaltung von Spezifikationen: Ein Metamodell der Notationen des Memorandums kann als ein Ausgangspunkt für die Entwicklung eines Fachkonzeptes eines Werkzeuges zur Verwaltung
von Komponentenspezifikationen verwendet werden.
Ziel des Beitrages ist es, ein Metamodell für die im Memorandum definierten Notationen zu
entwickeln. Der Beitrag ist folgendermaßen aufgebaut: Nach dieser Einleitung werden im
nächsten Abschnitt das Memorandum, der Begriff des Metamodells und verwandte Forschungsarbeiten knapp rekapituliert. Abschnitt 3 stellt das entwickelte Metamodell vor. Im
abschließenden vierten Abschnitt werden verschiedene Schlussfolgerungen gezogen und ein
Ausblick auf weitere Fragestellungen gegeben.
Zu Spezifizierende Sachverhalte
Vermarktungsebene
! Betriebswirtschaftlich-organisatorische
Merkmale
! Technische Randbedingungen
Tabellenform
Aufgabenebene
! Durch die Komponente automatisierte
betriebliche Aufgaben, Zweck
Rekonstruierte Fachsprache
! Begriffe der betrieblichen
Anwendungsdomäne
Rekonstruierte Fachsprache
! Eigenschaften, Qualitätsmerkmale
! Messgrößen und -verfahren
! Service-Level
Primär formelbasierte Schreibweise
! Reihenfolgebeziehungen zwischen
Diensten verschiedener Komponenten
! Reihenfolgebeziehungen zwischen
Diensten einer Komponente
Erweiterung der OCL um temporale
Operatoren
! Bedingungen (Invarianten, Vorund Nachbedingungen)
Object Constraint Language (OCL)
! Bezeichner für Fachkomponenten, Dienste,
Parameter, Datentypen und Fehler
! Signaturen von Diensten
! Zuordnung zu betrieblichen Aufgaben
Interface Definition Language (IDL)
Terminologieebene
Fachkomponente
verwendete Notationen
Qualitätsebene
Abstimmungsebene
Verhaltensebene
Bedarf einer
Spezifikation auf
Schnittstellenebene
Bild 2: Spezifikationsebenen und –aspekte sowie verwendete Notationen [Acke+02]
2
Theoretischer Hintergrund
2.1
Vereinheitlichte Spezifikation von Fachkomponenten
Das Memorandum verwendet sieben Ebenen zur Spezifikation (Bild 2) [Acke+02]. Jede Ebene fokussiert einen bestimmten Aspekt der Spezifikation einer Fachkomponente und berücksichtigt die Anforderungen einer Rolle im Entwicklungsprozess. Auf den einzelnen Ebenen
werden z T. unterschiedliche Notationen verwendet (OCL, OMG IDL etc.). Für eine ausführliche Diskussion der verschiedenen Spezifikationsaspekte sowie der verwendeten Notationen
sei auf die zitierte Literatur verwiesen.
2.2
Metamodelle
Der Begriff Metamodell wird in der Literatur nicht einheitlich verwendet. Allgemein kann ein
Metamodell als ein Modell eines Modells verstanden werden. Aus Sicht des Metamodells
wird das beschriebene Modell Objektmodell genannt. Bei der Metamodellbildung können
zwei Metaisierungsprinzipien unterschieden werden [Stra96, S. 17-28]:
-
Ein sprachbasiertes Metamodell repräsentiert die bei der Konstruktion des Objektmodells verwendete Modellierungssprache.
-
Ein prozessbasiertes Metamodell repräsentiert die bei der Konstruktion des Objektmodells durchgeführten Modellierungsschritte.
Für den hier verfolgten Zweck sind ausschließlich sprachbasierte Metamodelle von Relevanz,
sodass das Wort „Metamodell“ ausschließlich in diesem Sinne im Folgenden verwendet wird.
Demnach stellt ein Metamodell die in einem Modell verwendeten Konstrukte und deren Beziehungen dar. Diese Beziehungen definieren, welche Konstrukte in welchen Zusammenhängen erlaubt sind. Ein sprachbasiertes Metamodell ist vergleichbar mit der Grammatikdefinition einer Programmiersprache.
2.3
Verwandte Forschungsarbeiten
Allgemein werden Metamodelle in unterschiedlichen Forschungsbereichen verwendet. Anwendungsbeispiele finden sich bei der Evaluierung von objektorientierten Analysemethoden
[Stra96], der Modell Driven Architecture [KlWB03], der Auswahl von Workflowmanagementsystemen [Mühl99] oder der Darstellung und dem Vergleich von Ontologien [DGR02].
Ein spezielles Metamodell für das Memorandum ist den Autoren nicht bekannt, obgleich für
einzelne Sichten bereits syntaktische Regelwerke existieren, die als Metamodelle verstanden
werden können (Bild 3). Indes sind vorhandene Arbeiten bisher nicht in einem Gesamtmodell
integriert dargestellt. In der Arbeit von [Turo01] wird auf allgemeiner Ebene der Zusammenhang zwischen den Begriffen Fachkomponente, Dienst, Schnittstelle, betriebliche Aufgabe,
betriebliches Anwendungssystem, Implementierung und Eigenschaft mit Hilfe eines UMLKlassendiagramms geklärt. Dieses Modell kann als ein grobes Metamodell verstanden werden, das als Ausgangspunkt für ein detailliertes Metamodell dienen kann.
Spezifikationsebene Quellen
Vermarktungsebene [FeLo01]
Aufgabenebene
[Ortn97]
Terminologieebene
[Ortn97]
Qualitätsebene
Abstimmungsebene [CoTu00]
Verhaltensebene
[OMG01b]
Schnittstellenebene [OMG01a]
alle Ebenen
[Acke+02]
Bild 3: Ausgangspunkte für die Erstellung eines integrierten Metamodells
3
Entwicklung des Metamodells
In diesem Abschnitt wird das Metamodell für das Memorandum entwickelt (Bild 4). Als Modellierungssprache zur Repräsentation des Metamodells wird das Entity-Relationship-Model
(ERM) verwendet. Die Auswahl kann dahingehend begründet werden, dass diese Modellierungssprache relativ weit verbreitet und verständlich ist. Es werden im Folgenden die einzelnen Spezifikationsebenen betrachtet, wobei mit der Schnittstellenebene begonnen wird.
Die Schnittstellenebene besteht aus zwei „Interface“-Spezifikationen: Die eine Spezifikation
beschreibt die Dienste, die von der Komponente angeboten werden, die andere Spezifikation
(interface extern) die Dienste, die von der Komponente nachgefragt werden. Eine „Interface“Spezifikation wiederum enthält einfache sowie strukturierte Datentypen, Ausnahmezustände
sowie verschiedene Dienste. Die Dienste der Schnittstellenebene können einzelnen Aufgaben
der Aufgabenebene zugeordnet werden bzw. Datentypen sind mit Begriffen auf der Terminologieebene zu assoziieren.
Auf der Verhaltensebene werden Bedingungen definiert, die das Verhalten einzelner Dienste
festlegen. Auf der Ebene können eine Reihe von Bedingungen spezifiziert werden, wobei jede
einzelne Bedingung eindeutig einer Komponente zuzuordnen ist. Der Kontext einer Bedingung kann durch die Angabe eines Dienstes präzisiert werden, auf den sich die Bedingung
bezieht. Zur Formulierung der Bedingungen können die auf der Schnittstellenebene verwendeten Datentypen verwendet werden. Die angeführten Beziehungen zu Diensten und Datentypen der Schnittstellenebene dürfen sich nur auf die eigene und nicht auf die externe Schnittstelle beziehen. Diese Bedingung ist nicht explizit im Metamodell formuliert.
Die Abstimmungsebene besteht aus einer Reihe von Bedingungen, die sich zwingend auf einen Dienst der Schnittstellenebene beziehen. Neben der Kontextdefinition einer Bedingung,
kann eine Bedingung weiterhin Notwendigkeiten zur Abstimmung zu anderen Diensten der
Komponente definieren (Intra-Abstimmungsbedingung). Andererseits können Abstimmungen
zu Diensten anderer Komponenten beschrieben werden (Inter-Abstimmungsbedingung).
Während die Beziehungen „Kontext“ und „Intra-Abstimmung“ zwingend auf Dienste der
eigenen Schnittstelle verweisen, bezieht sich die Beziehung „Inter-Abstimmung“ zwingend
auf Dienste der externen Schnittstelle (diese Bedingung ist nicht im Metamodell formuliert).
1,1
extern
1,1
0,1
0,n
0,n
1,1
Ausnahmezustand
0,n
Verhaltensbedingung
1, 1
0,n
Verhaltensebene
1,1
0,n
Verwendung
0,1
0,1
0,1
1,1
1,1
0,n
Kontext
Abstimmungsbedingung
1, 1
0,n
Abstimmungsebene
1,1
1,1
0,n
0,n
strukturierte
Typen
einfache Typen
Dienst
0,n
Kontext
Intraabstimmung
Interabstimmung
Qualitätseigenschaft
1, 1
0,n
Qualitätsebene
1,1
1,1
0,n
0,n
Verwendung
0,n
1,1
0,n
Aufgabe
1,1
0,n
Aufgabenebene
Bild 4: Metamodell für die Notationen des Memorandums
Datentyp
1,1
0,n
InterfaceSpezifikation
1,1
eigene
1,1
Schnittstellenebene
1,1
1,1
Spezifikation
1,1
einer
1,1 Fachkomponente 1,1
1,1
0,n
0,n
0,n
Beziehung
0,n
0,1
Begriff
1,1
0,n
Terminologieebene
1,1
0,n
0,n
0,n
Beziehung
0,n
1,1
1,1
0,1
0,n
0,n
0,n
0,n
1,1
0,n
0,n
1,1
1,1
0,1
0,1
0,1
0,n
0,n
1,n
0,n
0,n
0,1
1,1
Vermarktungsebene
1,1
Freitext
Konditionen
Kontakt
Hersteller
Anforderung
Technologie
Artefakt
Domäne
Wirtschaftszweig
Kennung
Name
Die zur Zeit im Memorandum beschriebene Verfahrensweise zur Spezifikation der Qualitätsebene enthält nur wenige Hinweise auf erlaubte Spezifikationskonstrukte. Wird einer relativ
allgemeinen Auffassung gefolgt, kann die Qualitätsebene als eine Menge von Qualitätseigenschaften verstanden werden. Einzelne Qualitätseigenschaften können hierbei speziellen
Diensten einer Komponente zugeordnet werden, die sowohl durch die eigene als auch die
externe Schnittstelle definiert werden. Auf diese Weise ist es auch möglich zu spezifizieren,
dass die Dienste, die von einer Komponente nachgefragt werden, bestimmten Qualitätseigenschaften zu genügen haben.
Die Metamodellteilbereiche für die Aufgaben- und Terminologieebene sind analog aufgebaut.
Es wird jeweils auf eine explizite Darstellung von Satzbauplänen etc. verzichtet, um das entwickelte Metamodell überschaubar zu halten. Während auf der Aufgabenebene eine Reihe
von Aufgaben zuzüglich Beziehungen zwischen den Aufgaben definiert werden, sind auf der
Terminologieebene Begriffe und Begriffsbeziehungen zu beschreiben. Mögliche Beziehungen
zwischen Aufgaben sind bspw. „ist alternative Aufgabe“ oder „ist vorgelagert“. Beziehungen
zwischen Begriffen können bspw. sein „ist synonym“, „ist teil-synonym“ und „ist Beispiel
für“.
Die einzelnen Spezifikationsattribute der Vermarktungsebene können intuitiv sowohl als
ERM-Attribute einer Komponente (bspw. Name, Kennung) als auch als eigenständige Entitätstypen (bspw. Hersteller, Ansprechpartner) verstanden werden. Um eine einheitliche Übersetzung des Memorandums in das Metamodell vorzunehmen und eine – aus Sicht der Autoren
– wenig zielführende Diskussion zu vermeiden, ob bestimmte Informationen als „Entitäten“
oder als „Attribute“ von Entitäten zu verstehen sind, wurden sämtliche Spezifikationsattribute
dieser Ebene als Entitätstypen im Metamodell repräsentiert. Durch die Festlegung unterschiedlicher Kardinalitäten wird ausgedrückt, ob es sich um optionale oder verpflichtende
Angaben handelt bzw. ob einzelne Informationen für verschiedene Komponenten mehrfach
verwendet werden können.
4
Schlussfolgerungen und Ausblick
In diesem Beitrag wurde ein relativ grobes Metamodell des Memorandums vorgestellt, das
trotzdem mehr als 50 Konstrukte (Entitäts- und Beziehungstypen) enthält. Aus dem Metamodell wird ersichtlich, dass einzelne Konstrukte einer Komponentenspezifikation eine zentrale
Bedeutung besitzen. Beispielsweise werden Dienste der Schnittstellenebene auf der Verhaltens-, Abstimmungs-, Aufgaben- und evtl. der Qualitätsebene – zum Teil sogar mehrfach –
referenziert. Anderen Konstrukten kommt dagegen nur eine geringere Bedeutung zu. Im Memorandum wird bspw. ausgeführt, dass auf der Terminologieebene die Bedeutung von Begriffen zu klären ist, die auf sämtlichen Ebenen verwendet werden. Allerdings ist aus dem Metamodell ersichtlich, dass nur explizite Beziehungen zwischen Datentypen und Begriffen bestehen. Folglich gibt das Memorandum nur wenige Gestaltungsrestriktionen bzw. -hinweise,
welche Begriffe auf der Terminologieebene zwingend zu erläutern sind.
Im Rahmen der Untersuchung sind verschiedene Grenzen deutlich geworden, die im Folgenden angesprochen werden:
-
Subjektivität der Metamodellbildung: Das Bilden von Metamodellkonstrukten ist
nicht immer eindeutig. Bestimmte Sachverhalte können aus unterschiedlichen Perspektiven unterschiedlich dargestellt werden. Beispielsweise ist aus dem Memorandum nicht ersichtlich, ob zu einer Aufgabe auf der Aufgabenebene zwingend ein
Dienst auf der Spezifikationsebene angegeben werden muss oder ob dieser optional
ist. Dieser Sachverhalte sollte in einer künftigen Memorandumsversion geklärt werden.
-
Detaillierung der Abbildung: Es ist nicht immer offensichtlich, wie detailliert das Metamodell zu erstellen ist. Beispielweise wurde im vorgestellten Metamodell ein Dienst
auf der Schnittstellenebene durch jeweils ein Entitätstyp repräsentiert. Ebenso wäre es
denkbar, das Metamodell weiter zu detaillieren, indem darüber hinaus die Signaturen
eines Dienstes im Metamodell repräsentiert werden.
-
Verwendete Metamodellierungssprachen: Als Metamodellierungssprache wird das
ERM verwendet. Es stellt sich die Frage, ob die Verwendung anderer Metamodellierungssprachen zu Vorteilen führt, da diese evtl. eine höhere Ausdrucksmächtigkeit besitzen. Beispielsweise konnten in der verwendeten Modellierungssprache einzelne
Randbedingungen nicht im Metamodell, sondern nur natürlichsprachlich formuliert.
-
Im vorgestellten Metamodell wurde ausschließlich die primäre Notation berücksichtigt, ohne auf Eigenarten der sekundären Notation einzugehen. Es ist zu überlegen,
inwieweit die sekundäre Notation Erweiterungen und Ergänzungen am vorgestellten
Metamodell notwendig werden lässt. Beispielsweise wäre es denkbar, für sämtliche
Wörter einer natürlichsprachlichen Spezifikation – wie sie bspw. für die Abstimmungsebene vorgeschlagen wird – zu fordern, dass sie ebenso auf der Terminologieebene definiert werden. Andererseits kann der Standpunkt vertreten werden, dass bei
Verwendung der sekundären Notation generell nicht auf eine hohe Konsistenz zwischen den Abstimmungsebenen zu achten ist und daher sekundäre Notationen prinzipiell nicht im Metamodell zu berücksichtigen sind.
Die Autoren schlagen einerseits vor, die bei der Untersuchung aufgedeckten Probleme bei der
Überarbeitung und Weiterentwicklung des Memorandums zu berücksichtigen. Anderseits
kann das hier eingeführte Metamodell weiter gepflegt und Bestandteil einer künftigen Memorandumsversion werden, sodass die einleitend angeführten Nutzenpotenziale weitgehend realisiert werden können.
Literatur
[Acke+02]
Ackermann, J.; Brinkop, F.; Conrad, S.; Fettke, P.; Frick, A.; Glistau, E.; Jaekel, H.; Kotlar, O.; Loos, P.; Mrech, H.; Raape, U.; Ortner, E.; Overhage, S.; Sahm, S.;
Schmietendorf, A.; Teschke, T.; Turowski, K. Vereinheitlichte Spezifikation von Fachkomponenten - Memorandum des Arbeitskreises 5.10.3 Komponentenorientierte betriebliche Anwendungssysteme. http://wi2.wiwi.uni-augsburg.de/gi-memorandum.php.htm, Abruf 200303-01.
[BJPW99]
Beugnard, A.; Jézéquel, J.-M.; Plouzeau, N.; Watkins, D.: Making Components Contract Aware. In: IEEE Computer 32 (1999) 7, S. 38-45.
[CoTu00]
Conrad, S.; Turowski, K.: Vereinheitlichung der Spezifikation von Fachkomponenten auf der Basis eines Notationsstandards. In: J. Ebert; U. Frank (Hrsg.): Modelle und
Modellierungssprachen in Informatik und Wirtschaftsinformatik - Beiträge des Workshops
"Modellierung 2000", St. Goar, 5.-7. April 2000. Koblenz 2000, S. 179-194.
[DSWi98]
D’Souza, D. F.; Wills, A. C.: Objects, Components, and Frameworks with
UML - The Catalysis Approach. Reading, MA, et al. 1998.
[DGR02]
Davies, I.; Green, P.; Rosemann, M.: Facilitating an Ontological Foundation of
Information Systems with Meta Models. In: A. Wenn; M. McGrath; F. Burstein (Hrsg.): Proceedings of the 13th Australasian Conference on Information Systems (ACIS 2002), 3-6 December. Melbourne 2002, S. 937-947.
[FeLo01]
Fettke, P.; Loos, P.: Ein Vorschlag zur Spezifikation von Fachkomponenten
auf der Administrations-Ebene. In: K. Turowski (Hrsg.): Modellierung und Spezifikation von
Fachkomponenten: 2. Workshop im Rahmen der vertIS (verteilte Informationssysteme auf der
Grundlage von Objekten, Komponenten und Agenten) 2001, Bamberg, Deutschland, 05. Oktober 2001. Bamberg 2001, S. 95-104.
[Fisc00]
Fischer, B.: Specification-Based Browsing of Software Component Libraries.
In: Journal of Automated Software Engineering 7 (2000) 2, S. 179-200.
[Grif98]
Griffel, F.: Componentware - Konzepte und Techniken eines Softwareparadigmas. Heidelberg 1998.
[Han99]
Han, J.: An Approach to Software Component Specification. Proceedings of
1999 International Workshop on Component Based Software Engineering. Los Angeles, USA
1999.
[KlWB03]
Kleppe, A.; Warmer, J.; Bast, W.: MDA Explained: The Model Driven Architecture: Practice and Promise. Boston et al. 2003.
[Mühl99]
Mühlen zur, M.: Evaluation of Workflow Management Systems Using Meta
Models. Proceedings of the 32th Hawaii International Conference on Systems Science
(HICSS '99). Hawaii 1999.
[OMG01a] OMG: The Common Object Request Broker: Architecture and Specification:
Version 2.5. Framingham 2001.
[OMG01b] OMG: Unified Modeling Language Specification: Version 1.4. Needham 2001.
[Ortn97]
Ortner, E.: Methodenneutraler Fachentwurf - Zu den Grundlagen einer anwendungsorientierten Informatik. Stuttgart, Leipzig 1997.
[Same97]
Sametinger, J.: Software Engineering with Reusable Components. Berlin et al.
1997.
[Stra96]
Strahringer, S.: Metamodellierung als Instrument des Methodenvergleichs Eine Evaluierung am Beispiel objektorientierter Analysemethoden. Aachen 1996.
[SüEb97]
Süttenbach, R.; Ebert, J.: A Booch Metamodel. Fachberichte Informatik 5/97.
Koblenz 1997.
[Szyp02]
Szyperski, C.: Component Software - Beyond Object-Oriented Programming.
2. Aufl., London et al. 2002.
[Turo01]
Turowski, K.: Fachkomponenten - Komponentenbasierte betriebliche Anwendungssysteme. Habil.-Schr. Magdeburg 2001.
130
Spezifikation von Fachkomponenten mit der
UML 2.0
Jörg Ackermann
Universität Augsburg, Universitätsstraße
[email protected]
16,
86135
Augsburg,
Deutschland,
E-Mail:
Zusammenfassung. Die UML 2.0 bietet (im Vergleich zur UML 1.4) bessere Möglichkeiten zur
Modellierung von Komponenten. Dieser Beitrag stellt zunächst die relevanten UML 2.0 Konzepte
vor. Danach wird diskutiert, welche Auswirkungen sich daraus auf das Memorandum
„Vereinheitlichte Spezifikation von Fachkomponenten“ ergeben und wie das Memorandum
entsprechend weiterentwickelt werden könnte.
Schlüsselworte: Fachkomponente; (Software-)Komponente; Formale Spezifikation; UML 2.0
Die präzise und geeignete Spezifikation von Fachkomponenten ist eine wesentliche
Voraussetzung, damit sich der Bau von Anwendungssystemen aus am Markt gehandelten
Softwarekomponenten etablieren kann. Wichtig ist dabei vor allem die Standardisierung der
Komponentenspezifikationen, damit diese von allen beteiligten Parteien richtig verstanden
werden. Die Arbeitsgruppe 5.10.3. der Gesellschaft für Informatik hat einen Vorschlag
erstellt, wie Aufbau und Inhalt einer Spezifikation aussehen sollten. Für weitere Details siehe
das Memorandum „Vereinheitlichte Spezifikation von Fachkomponenten“ [Turo2002].
Das Memorandum verwendet auf der Verhaltens- und der Abstimmungsebene Elemente der
Unified Modeling Language (UML), insbesondere die Object Constraint Language (OCL).
Grundlage für das Memorandum war die damals verfügbare Version UML 1.4 [OMG2001].
Mittlerweile wurde die Version UML 2.0 [OMG2003] entwickelt, die kurz vor der
Verabschiedung steht. UML 2.0 bietet deutlich bessere Möglichkeiten zur Modellierung und
Spezifikation von Komponenten. Diese werden in diesem Beitrag vorgestellt und es wird
diskutiert, welche Möglichkeiten sich daraus für das Memorandum ergeben.
Im Kapitel 1 werden die Komponentenbegriffe in der UML und im Memorandum vorgestellt
und miteinander verglichen. Im Kapitel 2 werden die für Komponenten relevanten Konzepte
von UML 2.0 vorgestellt. Im Kapitel 3 wird diskutiert, wie die UML 2.0 in einer
weiterentwickelten Fassung des Memorandums berücksichtigt werden könnte. Abschließend
stellt das Kapitel 4 noch zwei Neuerungen in der OCL vor und zeigt, wie diese die
Spezifikation von Fachkomponenten vereinfachen.
1
Komponentenbegriffe in der UML und im Memorandum
In diesem Abschnitt wollen wir zunächst die Komponentenbegriffe in der UML und im
Memorandum vorstellen und diskutieren.
In der UML 2.0 wird eine Komponente folgendermaßen definiert [OMG2003, S. G-574]:
A component is a “modular part of a system that encapsulates its contents and whose
131
manifestation is replaceable within its environment. A component defines its behavior
in terms of provided and required interfaces. …”
Im Vergleich dazu betrachten wir die Definition aus dem Memorandum [Turo2002, S. 1]:
„Eine Komponente besteht aus verschiedenartigen (Software-) Artefakten. Sie ist
wiederverwendbar, abgeschlossen und vermarktbar, stellt Dienste über wohldefinierte
Schnittstellen zur Verfügung, verbirgt ihre Realisierung und kann in Kombination mit
anderen Komponenten eingesetzt werden, die zur Zeit der Entwicklung nicht
unbedingt vorhersehbar ist.“
Wir stellen dabei fest, dass beide Definitionen in wesentlichen Punkten übereinstimmen:
Abgeschlossenheit (in UML bezeichnet als „modular part“),
Kapselung (im Memorandum bezeichnet als „verbirgt ihre Realisierung“),
Verwendung wohldefinierter Schnittstellen.
Die Unterschiede in den Definitionen ergeben sich (nach Meinung des Autors) vor allem aus
der unterschiedlichen Sichtweise:
UML betrachtet Komponenten als Teile von Systemen und definiert daher
Komponenten in Bezug auf Systeme (Teil eines Systems, austauschbar).
Das Memorandum fokussiert mehr auf die Komponenten an sich (wiederverwendbar,
kombinierbar) und bringt zusätzlich betriebswirtschaftliche Aspekte (vermarktbar) ein.
Da beide Definitionen auf technischer Ebene weitgehend übereinstimmen, können nach
Meinung des Autors UML-Komponenten zur Modellierung und Spezifikation von
Komponenten gemäß des Memorandums eingesetzt werden.
Bei der Modellierung von Komponenten ist es sinnvoll, semantisch zwischen drei
verschiedenen Arten von Modellen zu unterscheiden: (software-unabhängige) konzeptionelle
Modelle, Spezifikationsmodelle und Implementierungsmodelle (vergleiche [Fowl1999]).
Diese Modellarten fokussieren auf unterschiedlichen Aspekten bei der Beschreibung einer
Komponente und ihres Umfelds.
Die UML unterscheidet zwischen logischen Komponenten (z.B. Businesskomponenten,
Prozesskomponenten) und physischen Komponenten (z.B. EJB-Komponente, CORBAKomponente, COM+-Komponente, .NET-Komponente). Leider wird diese Unterscheidung
nicht näher erläutert. Aber anhand der angegebenen Beispiele kann man davon ausgehen, dass
in konzeptionellen Modellen und in Spezifikationsmodellen logische Komponenten
verwendet werden, während physische Komponenten in Implementierungsmodellen zu finden
sind.
Im Memorandum erfolgt explizit keine weitere Unterscheidung von Komponenten wie in
UML. Bei der Spezifikation von Fachkomponenten steht allerdings die Außensicht der
Komponente und nicht ihre Implementierung im Vordergrund. Beim Einsatz von Modellen im
Memorandum sollte es sich daher um Spezifikationsmodelle handeln und es sollten logische
Komponenten verwendet werden.
2
Komponenten in der UML 2.0
Schon die UML 1.4 enthielt das Modellierungskonstrukt Komponente. Dieses war jedoch nur
132
für die Modellierung von physischen Komponenten vorgesehen. Für die Modellierung von
logischen Komponenten enthielt die UML 1.4 keine explizite Unterstützung, weshalb
verschiedene Autoren unterschiedliche Modellierungskonstrukte zur Beschreibung logischer
Komponenten heranzogen. So wurden z.B. Subsysteme [Andr2003, S. 27] oder Klassen mit
dem Stereotyp «comp spec» [ChDa2001] verwendet.
Die bedeutendste Änderung in der UML 2.0 besteht darin, dass auch logische Komponenten
mit dem Konstrukt Komponente modelliert werden können. Dadurch ergeben sich deutlich
bessere Möglichkeiten zur verständlichen und konsistenten Spezifikation von Komponenten.
Die wichtigsten Konstrukte und deren Verwendung werden nachfolgend dargestellt:
Eine Komponente wird als ein Rechteck mit dem Schlüsselwort «component» dargestellt.
Eine Komponente ist im UML Metamodell ein Subtyp von Klasse. Eine Komponente
kann daher Attribute und Methoden haben. Außerdem kann eine Komponente optional
eine interne Struktur haben und eine Menge von Ports zur Verfügung stellen.
«component»
Auftragsabwicklung
IKundenauftrag
IBestand
Bild 1: Komponente mit Schnittstellen
Die externe Sicht einer Komponente (Black-Box-Sicht) besteht aus der Komponente
und ihren Schnittstellen. Im Bild 1 sieht man die Darstellung einer Komponente
Auftragsabwicklung mit den Schnittstellen IKundenauftrag und IBestand.
Eine Komponente kann mehrere Schnittstellen haben. Dabei wird zwischen bereitgestellten und benötigten Schnittstellen unterschieden. Im Bild 1 werden exemplarisch
eine bereitgestellte (IKundenauftrag) und eine benötigte Schnittstelle (IBestand)
dargestellt.
«interface»
IKundenauftrag
Anlegen()
Annehmen()
Stornieren()
RechnungDrucken()
«component»
Auftragsabwicklung
«interface»
IBestand
Buche()
Reserviere()
BerechneBestandZum()
Bild 2: Detaillierte Darstellung der Komponenten-Schnittstellen
Sollen die Schnittstellen detaillierter dargestellt werden, kann man dafür das Konstrukt
Schnittstelle («interface») verwenden. Die Schnittstelle kann inklusive ihrer Operationen
133
(mit Parametern) und eventuell vorhandener Attribute modelliert werden. So sieht man
im Bild 2, dass die Schnittstelle IKundenauftrag die Operationen Anlegen, Annehmen,
Stornieren und RechnungDrucken zur Verfügung stellt (auf die Angabe der Parameter
wurde an dieser Stelle verzichtet).
Optional kann eine Komponente mit Ports versehen werden. Ein Port ist eine
Schnittstelle mit eigenem Bezeichner. Mit Ports kann man z.B. verschiedene
Zugangspunkte zu einer Komponente unterscheiden, die technisch dieselbe Schnittstelle
verwenden.
Optional kann ein Zustandsdiagramm mit einer Schnittstelle (oder einem Port)
verbunden werden, welches dynamische Bedingungen (Aufrufreihenfolge von
Operationen) expliziert.
Von der internen Sicht einer Komponente (White-Box-Sicht) wird gesprochen, wenn
die interne Struktur und die Realisierung einer Komponente dargestellt werden.
3
Erweiterungsvorschläge für das Memorandum
Um die Spezifikation von Fachkomponenten anhand des Memorandums einem möglichst
breiten Personenkreis zugänglich zu machen, werden im Memorandum bewusst allgemein
bekannte Notationstechniken vorgeschlagen. Deshalb werden im Memorandum auf der
Verhaltens- und der Abstimmungsebene Elemente der UML verwendet.
Die Spezifikation und Modellierung von Komponenten ist derzeit ein wichtiges Forschungsthema und wird daher von vielen Autoren untersucht. Entsprechend gab es in den letzten 2-3
Jahren einiges an neuen Entwicklungen und Erkenntnissen. Eines der Standardwerke zur
Modellierung von Komponenten mit UML ist [ChDa2001]. Viele Ansätze daraus sind in die
Version UML 2.0 eingeflossen.
Das Memorandum sollte die UML-Version 2.0 berücksichtigen und Gebrauch von ihren
Erweiterungen machen. Der Hauptgrund für diesen Vorschlag liegt darin, dass das
Memorandum nur so weiterhin seinem Anspruch gerecht werden kann, weit verbreitete und
bekannte Notationstechniken zu verwenden. Daneben ergeben sich auch einige
Verbesserungen und Vereinfachungen bei der Spezifikation von Fachkomponenten.
Auf dieser Zielsetzung aufbauend unterbreiten wir die folgenden Vorschläge zur
Weiterentwicklung des Memorandum. Alle beziehen sich jeweils auf die primäre
Notationstechnik.
1. Allgemein:
Eine Komponenten-Spezifikation sollte ein Diagramm enthalten, welches die externe
Sicht der Komponente darstellt. Dieses zeigt neben der Komponente auch die
bereitgestellten und benötigten Schnittstellen. Vergleiche dazu Bild 1. Dieses Diagramm
gilt für die gesamte Spezifikation und wird keiner Ebene zugeordnet.
Dienste, welche die Komponente von anderen Komponenten benötigt, werden als
benötigte Schnittstellen modelliert. Die Bezeichnung und die Spezifikation solcher
benötigter Schnittstellen erfolgt aus Sicht der Komponente selbst. (Man beachte, dass
verschiedene andere Komponenten die benötigten Dienste zur Verfügung stellen
können. Außerdem wird zum Zeitpunkt der Spezifikation im allgemeinen nicht bekannt
134
sein, welche konkrete Komponente dies überhaupt sein wird. Damit ist es nicht sinnvoll,
bei den benötigten Diensten auf konkrete Schnittstellen konkreter Komponenten zu
verweisen.) Anhand des Diagramms kann man erkennen, welche Interfaces eine
Komponente zur Verfügung stellt und welche von ihr benötigt werden. Daher kann auf
die Namenskonvention Extern verzichtet werden, die im Memorandum bisher als
Workaround verwendet wurde.
Eine Komponente kann in UML mehrere Interfaces haben. Daher sollte sich nicht, wie
im Memorandum als Beispiel zur Schnittstellenebene angegeben, der Name der
Fachkomponente aus dem Namen eines Interfaces ergeben.
2. Schnittstellenebene:
Hier sollte ebenfalls die UML zum Einsatz kommen. In einem speziellen Diagramm
(vergleiche Bild 2 für eine verkürzte Darstellung) werden die Schnittstellen der
Komponente detailliert beschrieben. Das Diagramm enthält für alle Schnittstellen die
zugehörigen Dienste (Operationen) mit ihren Parametern und Ausnahmen.
Bisher gab es durch die Verwendung der OMG IDL auf der Schnittstellenebene und der
UML OCL auf der Verhaltensebene einen Methodenbruch [Acke2001], der u.a. dazu
führte, dass die Spezifikationsobjekte der verschiedenen Ebenen nicht eindeutig
einander zugeordnet werden konnten. Dieses Problem wurde bisher durch
Namenskonventionen umgangen. Durch die Verwendung der UML auf der
Schnittstellenebene würde dieses Problem behoben. Außerdem könnte auf eine
Notationstechnik verzichtet werden.
Falls weiterhin eine Schnittstellenbeschreibung mit der OMG IDL benötigt wird, sollte
untersucht werden, ob diese aus der UML-Schnittstellenbeschreibung abgeleitet werden
kann. Dann könnte man, wenn benötigt, die Beschreibung in OMG IDL automatisch
generieren.
Durch diesen Vorschlag würde auf der Schnittstellen-, der Verhaltens- und der
Abstimmungsebene einheitlich die UML (zusammen mit der OCL) verwendet. Dies
passt auch sehr gut zum Vorschlag von Overhage, einen thematischen Bereich Technik
mit diesen drei Ebenen zu bilden. [Over2002]
3. Verhaltensebene
Manche Komponenten verwalten Geschäftsdaten, die im Zusammenhang mit der
Funktionalität und den Diensten der Komponente stehen. So könnte z.B. eine
Komponente Auftragsabwicklung alle bisher erfassten Kundenaufträge speichern und
verwalten. Die Gesamtheit der verwalteten Daten zu einem Zeitpunkt wird oft auch als
interner State der Komponente bezeichnet. Siehe dazu z.B. [ChDa2001, S. 123ff.].
Verwaltet die Komponente Geschäftsdaten, so muss auf der Verhaltensebene die
Abhängigkeit der Dienste vom internen State (und umgekehrt) spezifiziert werden. So
kann ein Dienst IKundenauftrag.Stornieren nur Aufträge stornieren, die der
Komponente bekannt sind. Oder ein Dienst IKundenauftrag.Anlegen wird, wenn
erfolgreich ausgeführt, einen neuen Auftrag in der Komponente anlegen.
In der Fallstudie [Acke2001] wurde vorgeschlagen, ein UML-Klassendiagramm zur
konzeptionellen Beschreibung des internen States zu verwenden. Dies wurde im
Memorandum aufgegriffen, in dem es optional ein UML-Klassendiagramm als
135
konzeptionelles Schema vorsieht, welches u.a. zur Abbildung des internen States der
Komponente verwendet werden kann.
Mit der UML 2.0 kann das konzeptionelle Schema passender als interne Sicht der
Komponente modelliert werden. Die zur Beschreibung des States notwendigen Entitäten
werden als Klassen mit dem Standard-Stereotyp «type» dargestellt. Dieses Modell dient
als eine Art Interface Information Model (vergleiche z.B. [ChDa2001]) und dient als
Grundlage, um Zusicherungen mit der OCL zu formulieren. Im Bild 3 ist ein
konzeptionelles Schema für die Komponente Auftragsabwicklung abgebildet. Dieses
enthält die Entitäten Kundenauftrag und Kunde, deren Eigenschaften (Attribute und
Assoziationen) in OCL-Ausdrücken verwendet werden können.
«component specification»
Auftragsabwicklung
«type»
Kundenauftrag
*
1
Auftragsnummer
Rechnungsbetrag
Rabatt
Ausgeliefert
«type»
Kunde
Kundennummer
Name
Adresse
Bild 3: Komponente mit spezifikationsrelevanten internen Typen
4. Abstimmungsebene
Die UML schlägt vor, Zustandsmaschinen als Standard zu verwenden, um Sachverhalte
auf der Abstimmungsebene zu beschreiben. Demgegenüber stehen die vom
Memorandum vorgeschlagenen temporalen Operatoren.
Es wird vorgeschlagen, beide Varianten als Alternativen in das Memorandum
aufzunehmen, da beide ihre spezifischen Vorteile haben. Dadurch wird die Konformität
zur UML gewahrt, ohne die Ausdrucksmächtigkeit zu verringern.
Durch die unterbreiteten Vorschläge ergeben sich die folgenden Vorteile:
Schnittstellen-, Verhaltens- und Abstimmungsebene verwenden mit der UML eine
einheitliche Notationstechnik.
Die Spezifikation auf diesen Ebenen
Ausdrucksmöglichkeiten von UML 2.0.
profitiert
von
den
erweiterten
Die Spezifikation bleibt konform zum Modellierungsstandard UML.
Auf einige der bisher notwendigen Workarounds (gedachte Komponente Extern,
Namenskonventionen zur Verbindung von Schnittstellen und Verhaltensebene) kann
verzichtet werden.
Mit diesen Vorschlägen wird also dafür plädiert, die UML konsequent auf den Ebenen
einzusetzen, wo sie die Spezifikation verbessern kann und wo sie international als
136
Modellierungsstandard anerkannt ist. Das sind derzeit die Schnittstellen-, Verhaltens- und
(mit Einschränkungen) die Abstimmungsebene. Das Memorandum leistet über diese Ebenen
hinaus einen wichtigen Beitrag, in dem es alle spezifikationsrelevanten Objekte identifiziert
und den Spezifikationsebenen zuordnet. Das Memorandum betrachtet dabei auch Objekte
(z.B. Terminologie und betriebliche Aufgaben), die von der UML nicht abgedeckt werden.
4
Verbesserungen bei der OCL 2.0
In den Fallstudien [Acke2001] und [Acke2003] sind in einigen Details Probleme bei der
Verwendung der Object Constraint Language (OCL) aufgetreten. Die Version UML 2.0
enthält einige Erweiterungen, die für die Spezifikation von Fachkomponenten relevant sind
und zwei der identifizierten Probleme beheben.
Es soll spezifiziert werden, dass während der Abarbeitung eines Dienstes ein anderer Dienst
aufgerufen wird, bei dem es sich um eine Nicht-Query-Methode handelt. Dies war bisher mit
OCL nicht möglich. Im Memorandum wurden solche Bedingungen auf der
Abstimmungsebene formuliert und für die Abstimmungsebene wurde (genau wegen dieses
Problems) postuliert, dass (im Gegensatz zum OCL-Standard) auch Nicht-Query-Methoden in
OCL-Ausdrücken verwendet werden können. Vergleiche dazu [Acke2001, S. 55]. Die OCL
2.0 bietet nun einen Operator hasSent (‘^’), mit welchem genau dieser Sachverhalt
ausgedrückt werden kann.
Außerdem ist es mit OCL 2.0 möglich, auf die Exportparameter eines Dienstes auch im
Kontext eines anderen Dienstes zuzugreifen. Dazu wurde der übliche Zugriff auf
Eigenschaften (durch Verwendung von ‘.’) auch auf die Exportparameter einer Methode
erweitert. Da ein solcher Zugriff in den Fallstudien notwendig war, wurde diese Möglichkeit
dort einfach vorweggenommen (allerdings durch Verwendung von ‘::’). Vergleiche dazu
[Acke2001, S. 39].
Die neuen Möglichkeiten mit der OCL sollen nun an einem Beispiel demonstriert werden.
Betrachten wir eine Beispielkomponente Auftragsverwaltung. Diese hat zwei Interfaces: das
bereitgestellte Interface IKundenauftrag (u.a. mit der Methode Annehmen) und das benötigte
Interface IBestand (u.a. mit der Methode Buche). Vergleiche dazu auch Bild 2. Der Dienst
Annehmen soll folgende Aufgaben ausführen:
Überprüfen, ob die Auftragsdaten konsistent sind und ob der Auftrag ausgeführt werden
kann,
Ermitteln, ob die erforderlichen Materialien verfügbar sind (bei einer anderen
Komponente über die Methode IBestand.BerechneBestandZum),
Buchen der erforderlichen Materialien (bei einer anderen Komponente über die
Methode IBestand.Buche),
Zurückmelden, ob der Auftrag angenommen werden kann.
Der Kundenauftrag kann nicht angenommen werden, wenn die erforderlichen Materialien
nicht verfügbar sind. Dies wird in der Nachbedingung in Bild 4 ausgedrückt. Der verfügbare
Bestand wird über die Methode IBestand.BerechneBestandZum() ermittelt und von dieser
Methode im Exportparameter Bestand zurückgegeben. In der dritten Zeile von Bild 4 sieht
man, wie mit Hilfe des OCL-Ausdrucks BerechneBestandZum().Bestand auf den
Exportparameter Bestand zugegriffen werden kann, um die Werte danach mit dem benötigten
137
Bestand vergleichen zu können.
Auftragsabwicklung::IKundenauftrag::Annehmen(in at: Auftrag): boolean
post: let benötigterBestand = ... in
let verfügbarerBestand = IBestand.BerechneBestandZum(...).Bestand in
if benötigtesMaterial > verfügbaresMaterial
then result = false endif
Bild 4: OCL-Bedingung mit Zugriff auf einen Exportparameter
Ist das benötigte Material vorhanden, wird von der Methode Annehmen die Methode Buche
von IBestand gerufen. Dieser Sachverhalt wird in der Nachbedingung im Bild 5 mit Hilfe des
OCL-Ausdrucks IBestand^Buche(...) ausgedrückt.
Auftragsabwicklung::IKundenauftrag::Annehmen(in at: Auftrag): boolean
post: if benötigtesMaterial <= verfügbaresMaterial
then IBestand^Buche(...) endif
Bild 5: OCL-Bedingung mit dem Operator hasSent (‘^’)
Literatur
[Acke2001] Ackermann, J.: Fallstudie zur Spezifikation von Fachkomponenten. In: K. Turowski (Hrsg.): 2.
Workshop Modellierung und Spezifikation von Fachkomponenten., Bamberg 2001, S. 1 – 66.
[Acke2003] Ackermann, J.: Zur Spezifikation der Parameter von Fachkomponenten. In: K. Turowski (Hrsg.): 5.
Workshop Komponentenorientierte betriebliche Anwendungssysteme (WKBA 5). Augsburg 2003,
S. 47 – 154.
[Andr2003] Andresen, A.: Komponentenbasierte Softwareentwicklung mit MDA, UML und XML. Hanser
Verlag, München 2003.
[ChDa2001] Cheesman, J.; Daniels, J.: UML Components. Addison-Wesley, Boston 2001.
[Fowl2000] Fowler, M.: UML Distilled – A Brief Guide to the Standard Object Modeling Language. AddisonWesley, 2000.
[OMG2001] OMG (Hrsg.): OMG Unified Modeling Language Specification, Version 1.4, September 2001.
Needham 2001.
[OMG2003] OMG (Hrsg.): Unified Modeling Language: Superstructure, Version 2.0, Stand 10.04.2003. URL:
http://www.omg.org/uml, Abruf am 2003-06-10.
[Over2002]
Overhage, S.: Die Spezifikation – kritischer Erfolgsfaktor der Komponentenorientierung. In: K.
Turowski (Hrsg.): 4. Workshop Komponentenorientierte betriebliche Anwendungssysteme
(WKBA 4). Augsburg 2002, S. 1 – 17.
[Turo2002]
Turowski, K. (Hrsg.).: Vereinheitlichte Spezifikation von Fachkomponenten. Memorandum des
Arbeitskreises 5.10.3 der Gesellschaft für Informatik. Augsburg 2002.
138
Erfahrungen im Umgang mit der
Spezifikation von Web Services
Andreas Schmietendorf*#, Reiner Dumke*, Daniel Reitz*#
* Otto-von-Guericke-Universität Magdeburg, Fakultät Informatik, IVS, Universitätsplatz 2, D39016 Magdeburg, Email: reitz|schmiete|[email protected]
# T-Systems Nova, Entwicklungszentrum Berlin, E21/STE, Wittestr. 30H, D-13509 Berlin, Email:
andreas.schmietendorf|[email protected]
Zusammenfassung: Der vorliegende Artikel analysiert die derzeitige Vorgehensweise bei der
Spezifikation von Web Services und vergleicht diese mit dem Vorschlag des GI-Arbeitskreises 5.10.3 in Bezug auf Fachkomponenten. Nach einer einführenden Darstellung der Web Service Technologie wird zuerst einmal auf potentielle Unterschiede bzw. Gemeinsamkeiten von
Fachkomponenten und Web Services eingegangen. Unter Berücksichtigung dieses Vergleichs und
des Memorandum „Vereinheitlichte Spezifikation von Fachkomponenten“ werden mehr als 120
im Internet verfügbare Web Services einer Bewertung hinsichtlich ihrer Spezifikation unterzogen.
Ziel dieser empirischen Analyse ist es die derzeitige Reife der Spezifikationen von Web Services
zu bewerten, zum anderen soll ein Diskussion angeregt werden, inwieweit das Memorandum auch
auf den Bereich der Web Services übertragen werden kann.
Schlüsselworte: Web Services, Fachkomponenten, Empirische Bewertung, Spezifikation, Spezifikationsebenen, Metriken
1 Einführung
Noch existiert keine einheitliche Auffassung, was genau unter einem Web Service zu verstehen ist. Sehr allgemein kann von einem softwarebasierten Service gesprochen werden, der
über das weltweit verfügbare Internet angeboten wird. Web Services kombinieren dabei die
Vorteile der komponentenbasierten Entwicklung, der Internet-Technologie und im zunehmenden Maße auch der Agententechnologie, dabei werden folgenden Vorteile erwartet:
•
Hoher Grad an Standardisierung und breite Akzeptanz innerhalb der Industrie
•
Synchrones und asynchrones Kommunikationsmodell
•
Unterstützung des Komponenten- und Integrationsparadigma
•
Einfache Vorgehensweise zur Kommunikation durch Firewalls hindurch
•
Brücke zwischen heterogenen Technologieansätzen
Bei Web Services handelt es sich um netzwerkbasierte Applikationen, die ihre im Internet
angebotenen Funktionen mittels des WSDL-Protokolls (Web-Service Description Language)
beschreiben, für den Informationsaustausch XML-Dokumente (eXtensible Markup Language)
verwenden und für den Aufruf entfernter Methoden bzw. die Datenübertragung das SOAPProtokoll (Simple Object Access Protocol) nutzen. Typischerweise erfolgt die Übertragung
der in XML-Dokumente verpackten Daten und Funktionsaufrufe auf der Basis des httpProtokolls, so dass auch durch Firewalls hindurch kommuniziert werden kann. Diese Eigen-
139
schaft bietet die Möglichkeit echte B2B1-Anwendungen zu entwickeln. Zur Lokalisierung im
Internet verfügbarer Web Services werden UDDI-Verzeichnisdienste (Universal Description,
Discovery and Integration) verwendet.
2 Vergleich von Fachkomponenten und Web Services
Innerhalb dieses Abschnitts wollen wir Fachkomponenten und Web Services miteinander
vergleichen. Im Gegensatz zu IV-technischen Komponenten bei deren Implementierung vielfältige technische Problemstellungen durch die Entwicklung zu lösen sind, handelt es sich bei
Fachkomponenten um anwendungsnahe Komponenten die eine Konzentration der Entwicklung auf die fachliche Problemstellung erlauben sollen. In Anlehnung an [Memorandum
2002] und unter Berücksichtigung der in [Frank 2001] getätigten Aussagen, kann eine FK
folgendermaßen charakterisiert werden:
Eine Fachkomponente ist eine anwendungsnahe Komponente, die eine bestimmte Menge von Diensten einer betrieblichen Anwendungsdomäne über eine wohl definierte
Schnittstellen anbietet und dabei das Kriterium der Abgeschlossenheit (d.h. Kapselung
der internen Struktur) erfüllt.
Demgegenüber kann ein Web Service in Anlehnung an [Gemeni 2002] folgendermaßen charakterisiert werden:
Unter Verwendung der Extensible Markup Language (XML) bieten Web-Services eine
standardisierte Vorgehensweise zur synchronen, als auch asynchronen Kommunikation
zwischen im Internet verteilten Anwendungen. Während die bisherigen Middlewareansätze immer eine technologieabhängige Vorgehensweise implizierten, bieten WebSerives eine technologieunabhängige und damit lose Kopplung von Anwendungssystemen. Ein Web-Service kann dabei fachlich begründete Funktionen im Sinn einer Fachkomponente beschreiben, anbieten und zentral verfügbare Verzeichnisse registrieren.
Der im Rahmen des GI-Arbeitskreises 5.10.3 entwickelte Vorschlag zur Vereinheitlichung
der Spezifikation von Fachkomponenten kann aus Sicht der Autoren auch zur Spezifikation
von Web Services herangezogen werden. Ziel dieses Vorschlags ist zum einem die Darstellung der benötigten Informationen um Fachkomponenten im Rahmen der eigenen Anwendung einsetzen zu können, zum anderen sollen mögliche Vorgehensweisen zur Beschreibung
(Notationen und Modelle) des Komponentenverhalten aufgezeigt werden. An dieser Stelle
wollen wir auf die detaillierte Darstellung der Spezifikationsebenen verzichten und verweisen
auf das unter www.fachkomponenten.de erhältliche Memorandum.
Die Spezifikationsebenen wurden primär zur Unterstützung einer auf der Basis von Komponenten durchzuführenden Entwicklung definiert. D.h. im Rahmen der Entwicklung einer neuen Anwendung soll die Verwendung am Markt gehandelter Komponenten (aus Black Box
Sicht) unterstützt werden. Web Services implizieren ebenfalls diese Zielstellung, gehen aber
noch einen deutlichen Schritt weiter. Während eingekaufte Fachkomponenten auch physisch
im Rahmen der Entwicklung verwendet werden, residieren Web Services innerhalb des Internet und können bei Verwendung im Rahmen der eigenen Anwendung auch dort verbleiben.
D.h. eine Anwendung kann auf der Basis im Netzwerk verteilter Fachkomponenten, diese
1
B2B Business to Business
140
basieren jetzt auf der Web Service-Technologie, realisiert werden. In diesem Sinne verändert
sich die Anwendungsentwicklung von der Komposition lokal verfügbarer Fachkomponenten
hin zur Integration im Netz verteilter Web Services.
Im Bezug auf das Memorandum des GI-Arbeitskreises 5.10.3 berücksichtigen die aktuellen
Kernstandards zu Web-Services im Rahmen der WSDL-Beschreibung lediglich die Schnittstellen- und zum Teil die Verhaltensebene. Die weiteren Ebenen, welche sich auf die Geschäftsprozessintergration (Abstimmungsebene), auf qualitative (Qualitätsebene), semantische
(Terminologie- und Aufgabenebene) und wirtschaftliche (Vermarktungsebene) Aspekte beziehen, werden durch derzeitige Standardisierungsansätze noch nicht explizit erfaßt.
3 Bewertung der Spezifikation von Web Services
Der erfolgreiche Einsatz eines konkreten Web Service innerhalb eines betrieblichen Anwendungssystems hängt maßgeblich von der Güte der angebotenen Spezifikation (Beschreibung)
des Web Service ab. Diese Beschreibung muß zumindest Aussagen über die angebotene
Funktionalität unter Berücksichtigung der wsdl-Spezifikation bereithalten und darüber hinaus
den Ort (typischerweise die URL) wo der Web Service im Internet erreichbar ist wiedergeben.
Um die derzeitige Vorgehensweise bei der Spezifikation von Web Service zu erfassen, wurden in Anlehnung an die Spezifikationsebenen des Memorandum, das folgende in der Abbildung 1 dargestellte Bewertungsmodell entwickelt.
Genügend
90%
Befriedigend
80%
Sehr gut
85%
Gut
Bewertungskriterien
Ungenügend
100%
Bewertungsmodell
Nur wsdl-Spezifikation und Access point – a
Allgemeine textliche Beschreibung der
möglichen Funktionen – b
Abrufbare Unterstützungsleistungen
im Fehlerfall – c
Referenzen wo der Web Service bereits
erfolgreich eingesetzt wurde – d
Beispiele potentiell unterstützter GP und
ausgewählte Fallbeispiele – e
75%
Informationen zu möglichen Fehlerzuständen in
Abhängigkeit der Parameterbelegung – f
Erfüllungsgrad
WEB SERVICE
Spezifikations Bewertung
Informationen zum Qualitätsverhalten und
möglichen Grenzwerten – g
Erläuterung semantischer Aspekte und
verwendeter Fachtermini - h
Abbildung 1: Modell zur Bewertung der Spezifikation von Web Services
141
Durch Anwendung der GQM-Methode (Goal – Question – Metric) entsprechend [Solingen
1999] wurden die folgenden „Top Level“ Bewertungskriterien identifiziert. Darüber hinaus
erfolgte eine Zuordnung dieser Bewertungskriterien zu den Spezifikationsebenen des Komponentenmemorandum.
− Spezifikation des Web Service enthält Aussagen zur wsdl-Beschreibung und den entsprechenden Zugriffspunkt im Internet – a. (vgl. Schnittstellenebene)
− Spezifikation des Web Service enthält eine grundlegende Beschreibung der angebotenen
Funktionen - b. (vgl. Aufgabenebene und Verhaltensebene)
− Spezifikation des Web Service enthält Informationen zu ggf. notwendigen Unterstützungsleistungen im Fehlerfall. - c. (vgl. Vermarktungsebene)
− Spezifikation des Web Service enthält Referenzen zu Anwendungen bei denen der Web
Service bereits erfolgreich eingesetzt wird. - d. (vgl. Vermarktungsebene)
− Spezifikation des Web Service enthält Informationen zu potentiell unterstützen Geschäftsprozessen und ausgewählten Fallbeispielen - e. (vgl. Abstimmungsebene)
− Spezifikation des Web Service enthält Informationen zu möglichen Fehlerzuständen in
Abhängigkeit der Parameterbelegung angebotener Methoden - f. (vgl. Verhaltensebene)
− Spezifikation des Web Service enthält Informationen zum Qualitätsverhalten und ggf.
möglichen Grenzwerten - g. (vgl. Qualitätsebene)
− Spezifikation des Web Service enthält Informationen zu den genutzten Fachtermini - h.
(vgl. Terminologieebene und Aufgabenebene)
− Spezifikation des Web Service enthält Aussagen zum Lizenzmodell und die Vorgehensweise zur Verrechnung der Nutzung (vgl. Vermarktungsebene) - i.
Zur Bewertung der Web Service Spezifikationen wurde ein einfaches, in Anlehnung an die
Schulnoten entwickeltes Modell genutzt. Um eine möglichst genaue Ermittlung der Bewertung zu unterstützen, erfolgte eine Detaillierung der Bewertungskriterien durch Bilden von
Subkriterien die erfüllt sein müssen um eine bestimmt Bewertung zu erreichen.
− ungenügend – Die Spezifikation berücksichtigt nur die Aspekte a und b. Die Verwendung
eines derart beschriebenen Web Service innerhalb industrieller Anwendungen ist nicht zu
empfehlen.
− genügend – Die Spezifikation berücksichtigt die Aspekte a, b und c. Die Verwendung
eines derart beschriebenen Web Service innerhalb industrieller Anwendungen ist möglich,
impliziert aber noch erhebliche Risiken.
− befriedigend – Die Spezifikation berücksichtigt die Aspekte a, b, c und d. Die Verwendung eines derart beschriebenen Web Service innerhalb industrieller Anwendungen ist
möglich und kann umfangreichen Tests unterzogen werden.
142
− gut – Die Spezifikation berücksichtigt die Aspekte a, b, c, d, e und f. Die Verwendung
eines derart beschriebenen Web Service innerhalb industrieller Anwendungen kann empfohlen werden, da bereits umfangreiche Erfahrungen zum Verhalten vorliegen.
− sehr gut – Die Spezifikation berücksichtigt alle Beschreibungsaspekte. Auf dieser Grundlage können genutzte Leistungen von Web Service verrechnet werden und sogenannte
Service Level Agreements (SLA) abgeschlossen werden.
Darüber hinaus wurde ein Erfüllungsgrad eingeführt, der die folgende Berechnung bei der
Ermittlung einer konkreten Bewertung zugrunde legt:
•
genügend – 100% für a, b und 90% für c
•
befriedigend - 100% für a, b und 90% für c sowie 85% für d
•
gut - 100% für a, b, 90% für c und 85% für d sowie 80% für e
•
sehr gut - 100% für a, b, 90% für c, 85% für d und 80% für e sowie 75% für f, g, h
4 Anwendung des Bewertungsmodells
Mittels des entwickelten Bewertungsmodells wurden bisher über 120 Web Services einer entsprechenden Analyse unterzogen. Die Auswahl der analysierten Web Services erfolgte nach
dem Zufallsprinzip, wobei das Web Service Verzeichnis www.xmethods.com und die dort
derzeit verzeichneten ca. 350 Web Services (Stand: Juli 2003) zugrunde gelegt wurden. Dabei
ergab sich die in Abbildung 1 dargestellte prozentuale Verteilung über alle bewerteten Web
Services hinweg.
deficient
sufficient
12%
usable
0%
good
very good
7%
32%
49%
Abbildung 2: Bewertung der Spezifikation von Web Service
Das auch aus Sicht der Autoren überraschend positive Ergebnis hinsichtlich des Reifegrades
heute verfügbarer Spezifikationen bzw. Beschreibungen zu Web Services bedarf noch einiger
relativierender Aussagen.
•
Zumeist werden bei der Spezifikation keine formalen Notationen verwendet.
143
•
Derzeit angebotene Web Service besitzen häufig nur geringen Funktionsumfang.
•
Explizite Darstellungen zur Terminologieebene finden sich nur selten.
•
Vermarktungs- und Aufgabenebene verschmelzen zumeist.
•
Abstimmungsebene wird zumeist nur implizit durch ein Anwendungsbeispiel erfaßt.
•
Web Service wurden explizit für die Wiederverwendung entwickelt.
•
Detailtiefe der Spezifikationsebenen wurde nur bedingt bewertet.
•
Viele Informationen sind im Internet durch Hyperlinks referenziert
•
Die angebotenen Web Services tragen nur teilweise einen kommerzielle Charakter
•
Einige Web Services sind mit verschiedenen Versionen abgelegt
Darüber hinaus ist anzumerken, dass derzeit keine Aussage getroffen werden kann, inwieweit
eine umfangreiche Spezifikation tatsächlich zum breiten Einsatz eines speziellen Web Service
beiträgt. Hier sollte ein Web Service Verzeichnis auch eine Referenz zu Projekten enthalten
wo der entsprechende Web Service bereits erfolgreich eingesetzt wird. Im Falle des hier verwendeten Web Service Verzeichnis findet sich ein solcher Hinweis nur zum Teil.
5 Schlußfolgerungen für das Memorandum
Aus den durchgeführten Untersuchungen lassen sich einige Vorschläge für potentielle Verbesserungen des Memorandum ableiten. So zeigt sich bei Web Services das Vermarktungsund Aufgabenebene typischerweise nicht getrennt betrachtet werden. Ebenso wird die Abstimmungsebene durch konkrete Einsatzbeispiele unterstützt. Als aus Sicht der Autoren negativ zu bewerten ist die geringe Verwendung formaler Notationen, wie z.B. der Unified Modelling Language (kurz UML) im Rahmen der Spezifikation von Web Services. Ebenso kritisch
ist die, je UDDI-Verzeichnisdienst, unterschiedliche Beschreibungsstruktur enthaltender Web
Services anzumerken. Aus Sicht der Autoren kann zur Harmonisierung der unterschiedlichen
Spezifikationsansätze das Memorandum (in einer überarbeiteten und auf den Bereich der Web
Services erweiterten Version) sinnvoll eingesetzt werden.
Die signifikanteste Veränderung aus Sicht der Autoren bezieht sich auf die Qualitätsebene.
Bedingt durch die Ausführung des Web Service innerhalb des Internet bietet sich theoretisch
die Möglichkeit einer Überwachung der Qualitätseigenschaften des Web Service durch einen
unabhängigen Meßdienst an, wie unter konzeptionell [Schmietendorf 2003] dargestellt. Auf
der Basis eines solchen unabhängigen Meßdienst (allg. wollen wir diesen als Measurement
Service bezeichnen) lassen sich Aussagen/Erfahrungen zur Effizienz, Zuverlässigkeit und
Wartbarkeit verhältnismäßig einfach gewinnen und im Rahmen der Spezifikation von Web
Services ebenfalls webbasiert potentiellen Interessenten anbieten. Dabei können z.B. folgende
Qualitätseigenschaften sukzessive erfaßt werden:
•
Betrachtung des Leistungsverhalten (Antwortzeit und Durchsatz)
•
Betrachtung der Verfügbarkeit der angebotenen Dienste
•
Änderungshäufigkeit der angebotenen Dienste. (z.B. neue Versionen)
•
Zeitliches Auslastungsverhalten (z.B. Wochenverlauf)
144
•
Darstellung einer Prioritäten gesteuerten Performance-Verhalten
Exemplarisch zeigt Tabelle 1 die erreichten Antwortzeiten des Web Services „CarRentalQuotesService“. Dieser Web Service dient zur Ermittlung der besten Angebote weltweit agierender Autovermietungen, eine umfassende Beschreibung zu diesem Web Service findet sich in
der Anlage zu diesem Artikel. Die Ermittlung der Performance und Verfügbarkeitscharakteristik im Tagesverlauf und gleichzeitige Bereitstellung im Rahmen der Spezifikation des Web
Service ermöglicht einem potentiellen Interessenten die Bemessung der eigenen Integrationsarchitektur bei Verwendung dieses Web Service. Insbesondere entfällt durch den Einsatz eines unabhängigen „Measurement Service“ das Problem der Referenzumgebung (vgl. [Memorandum 2002] S.13), da hier Software- und Runtime-Umgebung erfasst werden bzw. der Anbieter eines Web Service die Leistungseigenschaften sicherstellen muss (sofern entsprechende
SLA’s festgelegt wurden).
Tabelle 1: Performance und Verfügbarkeit „CarRentalQuotesService“
1400
1200
1000
800
3500
3000
2500
2000
1500
1000
500
0
600
400
200
0
03. 07. 03
04. 07. 03
04. 07. 03
04. 07. 03
04. 07. 03
04. 07. 03
05. 07. 03
04. 07. 03
05. 07. 03
05. 07. 03
05. 07. 03
05. 07. 03
05. 07. 03
06. 07. 03
19: 12
00: 00
04: 48
09: 36
14: 24
19: 12
00: 00
19: 12
00: 00
04: 48
09: 36
14: 24
19: 12
00: 00
M e a sur e m e n t p oi nt s
M e a sur e me nt p oi nt s
Messungen am Freitag
Messungen am Sonnabend
2000
4000
1500
3000
1000
2000
500
1000
0
0
05.07.03
19:12
06.07.03
00:00
06.07.03
04:48
06.07.03
09:36
06.07.03
14:24
06.07.03
19:12
07.07.03
00:00
06. 07. 03
07. 07. 03
07. 07. 03
07. 07. 03
07. 07. 03
07. 07. 03
08. 07. 03
19: 12
00: 00
04: 48
09: 36
14: 24
19: 12
00: 00
M e a sur e me nt p oi nt s
M e a sur e m e n t p oi nt s
Messungen am Sonntag
Messungen am Montag
Im speziellen Fall des „CarRentalQuotesService“ konnten z.B. die folgenden Erfahrungen
über einen Zeitraum von 1 Woche gewonnen werden.
•
Antwortzeitverhalten schwankt zwischen minimal 0.3 Sek. bzw. maximal 3.75 Sek.
•
Die Verfügbarkeit im Verlauf der Woche lag bei 96,4%
•
Am Wochenende verbessert sich das Antwortzeitverhalten (0,4 bis 1,4 Sekunden)
•
Größte Last während der Zeit von 09:00 Uhr bis 14:00 Uhr entsprechend GMT
•
Vermessen wurden die komplexeste Funktion des Web Service
•
Web Service wird bisher eher im europäischen Raum genutzt
145
6 Zusammenfassung
Die hier dargestellten Untersuchungen wurden insbesondere durch Erfahrungen bei der Anwendung des Memorandums im industriellen als auch akademischen Umfeld motiviert. Immer wieder wurde sowohl im Rahmen industrieller Projekte der Telekommunikationsbranche,
als auch innerhalb der Ausbildung die Kritik eines zu umfassenden Spezfikationsansatzes
geäußert. Die Schwerpunkte der Kritik lagen bei folgenden Punkten:
•
zu viele verwendete Notationen
•
nicht umsetzbar in der Praxis, da vom Aufwand her nicht zu vertreten
•
keine Entwicklungsumgebung die diesen Ansatz unterstützt
•
der Mehrwert einer entsprechenden Spezifikation kommt dem Entwickler nicht zugute
•
keine Möglichkeit die Güte der Spezifikation zu bewerten
Für die Autoren dieses Beitrags lag hier der Ansatzpunkt bereits erfolgreich eingesetzte
Beschreibungs- und Spezfikationsansätze im Umfeld von Web Services einer empirischen
Analyse zu unterziehen. Ziel war es, im Sinne einer „best practice“ Empfehlung, aus diesen
Ansätzen zu lernen und so zu einer Verbesserung des Spezifikationsansatzes für Fachkomponenten beizutragen. Im Rahmen dieser Untersuchungen können insbesondere die folgenden
beiden Aspekte zur Optimierung des Momorandum vorgeschlagen werden:
− Etablieren eine zum Memorandum korrespondierenden Bewertungsmodelle – im Sinne
eine „Buisiness Component Maturity Model – BCMM“
− Konzeptionelle Entwicklung einer unabhängigen Instanz zur Zertifizierung der angebotenen Fachkomponenten durch einen unabhängigen „dritten“. (vgl. Trust Center)
Für die weitere Vervollkommnung des Memorandum bedarf es aus Sicht der Autoren unbedingt einer Validierung des Spezifikationsansatzes im Sinne einer korrekten Identifizierung
der tatsächlich benötigten Informationen für die erfolgreiche Integration Fachkomponenten
bzw. Web Services. Der Schluss, dass eine Fachkomponente bzw. ein Web Services umso
besser spezifiziert seien, je umfangreicher die dabei zur Verfügung gestellt Informationen
sind, ist derzeit nicht bewiesen.
7 Quellenverzeichnis
[Frank 2001] Frank, U.; Jung, J.: Prototypische Vorgehensweise für den Entwurf anwendungsnaher Komponenten S. 57-74, in Proc. zur Verbundtagung VertIS 2001, Universität Bamberg, 2001
[Gemeni 2002] Der Markt für Web-Services - Erwartungen, Treiber, Investitionsabsichten,
Cap Gemeni Ernst & Young, Juni 2002
[Memorandum 2002] Ackermann, J.; Brinkop, F.; Conrad, S.; Fettke, P.; Frick, A.; Glistau,
E.; Jaekel, H.; Klein, U.; Kotlar, O.; Loos, P.; Mrech, H.; Ortner, E.; Overhage, S.;
Sahm, S.; Schmietendorf, A.; Teschke, T.; Turowski, T.: Vereinheitlichte Spezifikation
146
von Fachkomponenten. Memorandum des Arbeitskreises 5.10.3 - Komponentenorientierte betriebliche Anwendungssysteme, Februar 2002
[Schmietendorf 2001] Schmietendorf, A.; Dumke, R.: Spezifikation von Softwarekomponenten auf Qualitätsebene, in Turowski, K.: 2. Workshop Modellierung und Spezifikation
von Fachkomponenten, Bamberg/Deutschland, Oktober 2001
[Schmietendorf 2003] Schmietendorf, A.; Dumke, R.; Wipprecht, M.: SLA Management Herausforderungen im Rahmen von Web Service basierten Infrastrukturen, in Proc. 16.
cecmg-Jahrestagung & 6. EuroCMG Conference (only CD-ROM), Hannover/Deutschland, April 2003
[Solingen 1999] Solingen, v. R.; Berghout, E.: The Goal Question Metric (GQM) Method,
McGraw Hill, 1999
147
Anlage – Beispiel der Spezifikation “CarRentalQuotesService”
Im Folgenden soll die Orginal-Spezifikation des Web Service “CarRentalQuotesService” als
ein ausgewähltes Beispiel wiedergegeben wurde. Diese wurde unverändert vom Web Service
Verzeichnis www.xmethods.com übernommen. Bei diesem Web Service handelt es sich um
einen Dienst der die Angebote verschiedener Autovermietungsfirmen miteinander vergleicht.
Dafür werden die im Internet publizieren Angebote aktuell miteinander verglichen und so der
aktuell günstigste Anbieter identifiziert. Leider bietet dieser Service nicht die Möglichkeit
einer direkten Bestellung, dafür muss auf bewährte Systeme umgestiegen werden.
Bewertete wurde dieser Web Service entsprechend des unter Abschnitt 3 eingeführten Bewertungsmodells mit „gut“. Dabei wurden allerdings nicht nur die im Folgenden dargestellten
Informationen bewertet, sondern auch die unter http://www.dsdata.co.uk/WS/ verfügbaren
Informationen bzw. das dort abrufbare Beispiel zum Einsatz des Web Service. Die im Rahmen des Artikels dargestellten Messungen zur Verfügbarkeit bzw. Performance beziehen sich
ebenfalls auf diesen Web Service.
Detailed Description
This service takes the pain out of comparing car rental quotes from the major rental companies. You submit your criteria, such as dates/times and locations and the service locates the
best current deals on the Internet returning a list of quotes ordered by price. The service actually visits each car rental site, in parallel, automatically to find the best deal at that moment.
Note that this is different to most car rental search engines out there that rely on a database for
quotes which may respond quickly but are often misleading and have out-of-date results. The
user is provided with completely independent quotes and left to book the car rentals as he/she
sees fit.
Usage Notes
The main interface is "getQuotes()" which gets the actual car rental quotes. To feed in the
appropriate codes for countries, locations, results-currencies and car types you can optionally
call getCountries(), getLocations(), getCurrencies() and getCarTypes(). These are handy for
building a fully-functional client.
More information, including a C# demonstration client is available for free download from
http://www.dsdata.co.uk/WS/.
To use the service from the web you can try http://www.searchbookgo.com/ which uses these
web services at the back end as well. The service is totally independent and free to use. Please
feedback or comments to [email protected].
RPC Profile for Service "Real Time Car Rental Quotes"
As a convenience for those who need to manually configure basic SOAP RPC calls, we provide this page which summarizes all the necessary parameters need to configure a SOAP RPC
call. This information is derived automatically from the service WSDL file. It is a subset of
what can be found in the more comprehensive WSDL Analyzer available from the service
detail page.
148
Method Name
getQuotes
Endpoint URL
http://wavendon.dsdata.co.uk/axis/services/CarRentalQuotes
SOAPAction
Method Namespace URI
urn:SBGCarRentalQuotes.sbg.travel.ws.dsdata.co.uk
carType
string
country
string
currency
string
pickupDate
dateTime
pickupLocation
string
returnDate
dateTime
returnLocation
string
clientID
string
userEmail
string
Output Parameters
getQuotesReturn
ArrayOf_tns2_CarRentalQuoteResponse
Method Name
getCountries
Endpoint URL
Input Parameters
SOAPAction
Input Parameters
ArrayOf_xsd_string
Output Parameters
getCountriesReturn
Method Name
getLocations
Endpoint URL
SOAPAction
Input Parameters
country
string
149
ArrayOf_xsd_string
Output Parameters
getLocationsReturn
Method Name
getCurrencies
Endpoint URL
SOAPAction
Input Parameters
ArrayOf_xsd_string
Output Parameters
getCurrenciesReturn
Method Name
getCarTypes
Endpoint URL
SOAPAction
Input Parameters
Output Parameters
150
getCarTypesReturn
ArrayOf_xsd_string
http://www.seda.wiai.uni-bamberg.de/mkwi2004/index.htm
Weitere aktuelle Informationen zur Teilkonferenz
MobIS'04 finden sich im WWW unter:
Weitere Informationen:
http://www.mkwi04.de
Die Anmeldung zur Teilkonferenz MobIS'04 erfolgt
zentral über die Multikonferenz MKWI'04. Informationen zu den Tagungsbeiträgen sowie ein Anmeldeformular finden sich auf den Web-Seiten der Multikonferenz unter:
Anmeldung:
http://www.mkwi04.de
Eine Wegbeschreibung sowie weitere Informationen
zu Anreise und Unterkunft finden sich auf den WebSeiten der MKWI'04:
Prof. Dr. M. Rebstock
Fachhochschule Darmstadt
Fachbereich Wirtschaft
Haardtring 100
64295 Darmstadt
E-Mail [email protected]
Organisation:
Prof. Dr. J. Becker (Uni Münster),
Dr. M. Bertram (Commerzbank AG, Frankfurt),
Prof. Dr. W. Esswein (TU Dresden),
Prof. Dr. U. Frank (Uni Koblenz-Landau),
Prof. Dr. G. Knolmayer (Uni Bern),
K.-W. Müller (BearingPoint GmbH, München),
Dr. M. Nüttgens (Uni des Saarlandes),
Prof. Dr. A. Oberweis (Uni Frankfurt),
Prof. Dr. M. Rebstock (FH Darmstadt),
Prof. Dr. E. J. Sinz (Uni Bamberg),
Prof. Dr. K. Turowski (Uni Augsburg)
Universität Duisburg-Essen
Standort Essen
Universitätsstraße 2
45141 Essen
Programmkomitee:
Veranstaltungsort:
Universität Duisburg-Essen,
Standort Essen
10. März 2004
Multi-Konferenz
Wirtschaftsinformatik
(MKWI'04)
im Rahmen der
MobIS'04
12. GI-Fachtagung
Einladung und Programm
GI-Fachgruppe WI-MobIS
InformationssystemArchitekturen:
Modellierung betrieblicher
Informationssysteme
Im Anschluss an die Tagung lädt das Leitungsgremium der Fachgruppe zur Mitgliederversammlung der
GI-Fachgruppe WI-MobIS ein.
Alle vom Programmkomitee ausgewählten Beiträge
wurden in einem doppelt-blinden Verfahren von jeweils zwei Gutachtern beurteilt. Die Beiträge werden
ergänzt durch einen eingeladenen Vortrag und eine
Abschlussdiskussion.
Inhaltliche Schwerpunkte dieser Tagung bilden die
Modellierung von Funktionen, Prozessen und Informationssystemen sowie die Metamodellierung von
Werkzeugen und Sprachen. Neben praxisorientierten
Aspekten werden dabei auch grundlegende Fragen
der Modellierung behandelt.
Ziel der Tagung ist es, aktuelle Fragen der Architektur und der Modellierung betrieblicher Informationssysteme (IS) auf breiter fachlicher Basis und in einem
Dialog von Wissenschaft und Praxis zu diskutieren.
Zielsetzung und Themen
Kaffeepause
11:00
B. Brigl, A. Häber, T. Wendt, A. Winter
(Uni Leipzig)
Ein 3LGM2 Modell des Krankenhausinformationssystems des Universitätsklinikums Leipzig und seine Verwertbarkeit für
das Informationsmanagement
Mittagspause
12:15
13:00
14:00
K. Sarshar, P. Loos
(Uni Mainz)
Klassifikation von Sprachen zur Modellierung medizinischer Behandlungspfade
Modellierung von Funktionen
und Prozessen
S. Overhage
(Uni Augsburg)
Zur Spezifikation von Komponenten der
Informationssystementwicklung mit Softwareverträgen
11:30
Modellierung von
Informationssystemen
G. Keller
(SAP AG)
Wertorientierte Geschäftsprozessgestaltung - Erfahrungsbericht aus dem
Bankensektor -
10:15
Eingeladener Vortrag
Die Fachgruppe lädt herzlich ein zur 12. Fachtagung
"Informationssystem-Architekturen und Modellierung
betrieblicher Informationssysteme".
Begrüßung
M. Rebstock
(FH Darmstadt)
10:00
(Informationssystem-Architekturen: Modellierung
betrieblicher Informationssysteme)
Veranstalter
Mittwoch, 10. März
Kaffeepause
15:30
Abschlussdiskussion
Moderation:
M. Rebstock
(FH Darmstadt)
Mitgliederversammlung der
(inkl. Neuwahl des Leitungsgremiums)
Moderation:
E. J. Sinz
(Uni Bamberg)
17:30
18:00
Sitzung des Leitungsgremiums der GIFachgruppe WI-MobIS am 10. März um
09.00 Uhr.
Abendveranstaltung im Rahmen der
MKWI'04
E. Heinemann, E. Ortner, J. Sternhuber
(TU Darmstadt)
Sprachbasierte Wissensrekonstruktion am
Beispiel des Einkommensteuergesetzes
16:45
19:00
P. Fettke, P. Loos
(Uni Mainz)
GenGraph: A Multi-Grammar and MultiPerspective Business Modeling Tool –
Overview of Conceptualization and
Implementation
16:00
Metamodellierung von
Werkzeugen und Sprachen
R. Braun, W. Esswein, A. Gehlert
(Uni Dresden)
Berücksichtigung temporaler Aspekte bei
der Geschäftsprozessmodellierung im
eGovernment
14:45
Arbeitskreise der Fachgruppe WI-MobIS
Arbeitskreis AK WI-ZobIS:
Zeitorientierte betriebliche Informationssysteme (bisher AK 5.10.2)
2002 abgeschlossen
Arbeitskreis AK WI-DWH:
Modellierung und Nutzung von DataWarehouse-Systemen (bisher AK 5.10.4)
Prof. Dr. Elmar J. Sinz
Universität Bamberg
Feldkirchenstr. 21
96045 Bamberg
Tel.: 0951/863-2512
e-mail: [email protected]
Prof. Dr. Gerhard Knolmayer
Institut für Wirtschaftsinformatik
Engehaldenstr. 8
CH 3012 Bern
Tel.: 0041 31/631-3809
Arbeitskreis AK WI-KobAS: Komponentenorientierte betriebliche Anwendungssysteme (bisher AK 5.10.3)
Arbeitskreis AK WI-EPK: Geschäftsprozessmanagement mit Ereignisgesteuerten
Prozessketten
Prof. Dr. Klaus Turowski
Universität Augsburg
Lehrstuhl für Wirtschaftsinformatik II
Universitätsstr. 16
86159 Augsburg
Tel.: 0821/598-4431
Dr. Markus Nüttgens
Wirtschaftsinformatik II (Lehrstuhlvertretung)
Universität Trier
Postfach 3825
54286 Trier
Tel.: 0651/201-2857
Fachexperten
Prof. Dr. Manfred Esser
Universität St. Petersburg
Prof. Dr. Gerhard Knolmayer
Institut für Wirtschaftsinformatik
(Adresse siehe oben)
Hinweise für Autoren
Veröffentlichungssprachen sind entweder Deutsch oder Englisch. Der Umfang sollte sechs
A4-Seiten (einschließlich Bildern) nicht überschreiten. Die Seitenbegrenzungen sollen von oben
2,5 cm von rechts, links und unten 2 cm betragen. Von der Benutzung von Seitennummern,
Kopf- und Fußzeilen ist abzusehen. Die Nummerierung soll mit Bleistift auf der Rückseite erfolgen. Als Schriftart soll eine 12-Punkt Times-Roman benutzt werden. Dies gilt nicht für die Überschriften. Der Zeilenabstand beträgt 1,5 Zeilen. Der Text soll numerisch gegliedert sein. Das
Instrumentarium der Mathematik soll soweit Verwendung finden, als es sich um formale Zusammenhänge handelt. Daneben ist jedoch eine verbale Kommentierung wichtiger Aussagen
erwünscht. Bilder sollen nummeriert und mit Unterschriften versehen sein.
Literaturhinweise werden im Text durch eine sechs- bis siebenstellige Kurzbezeichnung in eckigen Klammern gekennzeichnet und am Ende des Beitrags zusammengefasst. Die Kurzbezeichnung setzt sich aus den Zunamen der Autoren und dem Erscheinungsjahr zusammen. Zur Unterscheidung mehrerer gleicher Kurzbezeichnungen kann ein Kleinbuchstabe angehängt werden. Beispiel:
[FeSi90] Ferstl, Otto K.; Sinz, Elmar J.: Ein Vorgehensmodell zur Objektmodellierung betrieblicher Informationssysteme im semantischen Objektmodell (SOM), In: Wirtschaftsinformatik, 33 (1991) 6, S. 477-491.
Jedem Beitrag sollen vorangestellt sein:
Titel (deutsch oder englisch),
Autorennamen mit vollen Vornamen und akademischen Graden,
Anschrift der Autoren zur Veröffentlichung (möglichst Firma/Institut),
Zusammenfassung (eine halbe Seite, deutsch oder englisch).

Rundbrief des FA 5.2 Informationssystem-Architekturen

Transcription

Similar documents

Technische Zuverlässigkeit 2009

Fairy chess problems - Jaroslav Stun`s Chess problems

Anwendung der Nutzwertanalyse zur Bewertung von Strategien zur

Konfigurationsmanagement komponentenorientierter betrieblicher

RESTful APIs - Eine Übersicht

Übungsblatt 4 – Lösungsvorschläge

Warum Responsive Web Design?

19" Widescreen Rackmount-Konsole mit

Tutorial Parametermanager