final version
Modellierung und Bewertung
von Integration
in Krankenhausinformationssystemen
Dissertation
zur Erlangung des akademischen Grades
Dr. rer. med.
an der medizinischen Fakult¨at
der Universit¨at Leipzig
eingereicht von:
Dipl.-Inform. Med. Thomas Wendt
geboren am 08.09.1974
angefertigt an:
Institut f¨
ur Medizinische Informatik, Statistik und Epidemiologie
der Universit¨at Leipzig
Betreuer:
Prof. Dr. Alfred Winter
Beschluss u
¨ber die Verleihung des Doktorgrades vom:
31.01.2006
Thomas
Wendt
Digital unterschrieben von
Thomas Wendt
CN: CN = Thomas Wendt, C =
DE, O = Universitaet Leipzig, OU
= IMISE
Ursache: Ich bin der Verfasser
dieses Dokuments
Datum: 2006.08.01 17:01:19
+02'00'
Bibliographische Beschreibung
Thomas Wendt
Modellierung und Bewertung von Integration in Krankenhausinformationssystemen
Universit¨at Leipzig, Dissertation
240 Seiten, 117 Literaturquellen ,
76 Abbildungen, 8 Tabellen,
2 Anlagen
Referat:
Die Dissertation behandelt die Modellierung und Bewertung der Integration von Anwendungssystemen eines Informationssystems.
Grundlage f¨
ur die Modellierung ist das Metamodell 3LGM2 , das hier zum 3LGM2A
erweitert wird. Bei der Erweiterung werden Standards f¨
ur Informationssystemarchitekturen ber¨
ucksichtigt, um eine flexible Modellierung zu erm¨oglichen. Dabei wird auch eine
¨
vergleichende Ubersicht
u
ur Informations¨ber Rahmenwerke und zugeh¨orige Standards f¨
systemarchitekturen erarbeitet.
Aufbauend auf dem Metamodell 3LGM2A werden Bewertungsans¨atze f¨
ur die Integrationvon Anwendungssystemen erarbeitet. Damit k¨onnen Informationssysteme hinsichtlich der Erf¨
ullung von Integrationsanforderungen, der Abh¨angigkeit von Anwendungssystemen und der Heterogenit¨at der Integrationsinfrastruktur bewertet werden.
F¨
ur die systematische Betrachtung von Integrationsanforderungen werden Anforderungskategorien erarbeitet. Sie werden u. a. beim Entwurf eines Dom¨anenkonzeptes verwendet, das die formale Analyse der Erf¨
ullung von Integrationsanforderungen erm¨oglicht.
Dom¨anen sind dabei Mengen von Anwendungssystemen mit bestimmten Integrationsanforderungen bzw. mit einem bestimmten Integrationsstatus.
F¨
ur die Bewertung der Abh¨angigkeit und der Heterogenit¨at werden verschiedene Kennzahlen, z. B. Abh¨angigkeitsgrade und Heterogenit¨atsgrade, entwickelt, die eine quantitative Bewertung der Inegration erm¨oglichen.
Modellierung und
Bewertung
von Integration
in Krankenhausinformationssystemen
Thomas Wendt
Fu¨r Kathrin und Lukas
Danksagung
Die vorliegende Arbeit wurde am Institut f¨
ur Medizinische Informatik, Statistik und Epidemiologie der Universit¨
at Leipzig angefertigt. Sie wurde von Herrn Professor Dr. Alfred Winter
¨
betreut, dem ich hiermit f¨
ur die Uberlassung
des Themas sowie f¨
ur die freundschaftliche und
engagierte Begleitung und Unterst¨
utzung mit anregenden wissenschaftlichen Gespr¨
achen herzlich danke.
Die Anfertigung der Arbeit w¨
are ohne die Unterst¨
utzung meiner Familie nicht m¨
oglich gewesen. Ich danke meiner Frau Kathrin f¨
ur das Ertragen meines R¨
uckzuges in unser Arbeitszimmer,
f¨
ur das st¨
andige Motivieren zum Dranbleiben“ und f¨
ur das wiederholte sehr aufmerksame Kor”
rekturlesen. Ich danke unserem kleinen Sohn Lukas f¨
ur sein fr¨
ohliches Lachen, mit dem er mir
viel Kraft geschenkt hat. Meinem Bruder Stefan danke ich f¨
ur aufmerksames Korrekturlesen.
Meinem Kollegen Gert Funkat danke ich f¨
ur aufmerksames Korrekturlesen trotz hoher Arbeitsbelastung und wertvolle methodische Hiweise.
Herrn Professor Dr. Wilhelm Hasselbring von der Universit¨
at Oldenburg danke ich f¨
ur die
M¨oglichkeit zum zweimaligen Vorstellen meiner Ergebnisse an seinem Institut mit anregenden
Diskussionen.
3
Inhalts¨
ubersicht
Inhalts¨
ubersicht
I
Inhaltsverzeichnis
III
Kastenverzeichnis
IX
Abbildungsverzeichnis
XI
Tabellenverzeichnis
XV
A Einleitung
1
I
5
Grundlagen
1 Bewertung der Integration: Ziel und Grundannahmen
7
2 Integrationsanforderungen
11
3 Informationssystemarchitekturen — Eine Einf¨
uhrung
21
4 Standards f¨
ur Informationssystemarchitekturen
31
5 Gesch¨
aftsprozessmodellierung — Eine Einf¨
uhrung
77
II
85
Architekturmodellierung
6 Einf¨
uhrung in das
3LGM2
87
¨
7 Flexible Architekturmodellierung — Uberarbeitung
des 3LGM2
99
III Architekturbewertung
117
8 Theoretische Vorbereitung der Integrationsbewertung
119
9 Die Erf¨
ullung von Integrationsanforderungen
129
10 Abh¨
angigkeit von Anwendungsbausteinen
157
11 Heterogenit¨
atsbewertung von Kommunikationsverbindungen
171
Z Abschluss
187
Anhang A
Anhang B
Anforderungskatalog f¨
ur die Informationsverarbeitung im Krankenhaus
(Auszug)
UML-Diagramme f¨
ur die Ebenen des
3LGM2A
i
v
Literaturverzeichnis
ix
Stichwortverzeichnis
xv
I
Inhaltsverzeichnis
Inhalts¨
ubersicht
I
Inhaltsverzeichnis
III
Kastenverzeichnis
IX
Abbildungsverzeichnis
XI
Tabellenverzeichnis
A Einleitung
A.1 Gegenstand, Problematik, Motivation
A.1.1 Gegenstand . . . . . . . . . . .
A.1.2 Problematik . . . . . . . . . . .
A.1.3 Motivation . . . . . . . . . . .
A.2 Zielsetzung und Fragestellung . . . . .
A.2.1 Zielsetzung . . . . . . . . . . .
A.2.2 Fragestellung . . . . . . . . . .
I
XV
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Grundlagen
5
1 Bewertung der Integration: Ziel und Grundannahmen
1.1 Bewertungsziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Grundannahmen der Architekturbewertung . . . . . . . . . . . . . . . . . . . .
2 Integrationsanforderungen
2.1 Vorbereitung . . . . . . . . . . . . . . . .
2.2 Kategorien von Integrationsanforderungen
2.2.1 Physische Integration . . . . . . .
2.2.2 Datenintegration . . . . . . . . . .
2.2.3 Funktionale Integration . . . . . .
2.2.4 Semantische Integration . . . . . .
2.2.5 Kontextintegration . . . . . . . . .
2.2.6 Pr¨
asentationsintegration . . . . . .
2.2.7 Zugriffsintegration . . . . . . . . .
1
1
1
2
3
3
3
4
7
7
8
.
.
.
.
.
.
.
.
.
11
11
13
14
14
15
16
16
18
19
3 Informationssystemarchitekturen — Eine Einf¨
uhrung
3.1 Vorbemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Architektur: Komponenten und ihre Beziehungen . . . . . . . . . . . . . . . . .
21
21
22
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
III
Inhaltsverzeichnis
3.3
3.4
Architekturstile . . . . . . . . . . . . . . . . . . . . . . . . . .
Architekturstile f¨
ur Informationssysteme — Metamodelle und
3.4.1 Architekturstile und Metamodelle . . . . . . . . . . .
3.4.2 Architekturstile und Referenzmodelle . . . . . . . . .
3.4.3 Bestimmung von Architekturstilen . . . . . . . . . . .
. . . . . . . . . .
Referenzmodelle
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
4 Standards f¨
ur Informationssystemarchitekturen
4.1 Orientierung durch Rahmenwerke . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Technische Rahmenwerke f¨
ur Informationssystemarchitekturen . . . . . . .
4.2.1 Das OSI-Referenzmodell der ISO . . . . . . . . . . . . . . . . . . . .
4.2.2 Das Referenzmodell f¨
ur offene verteilte Informationsverarbeitung der
4.2.3 Die Object Management Architecture . . . . . . . . . . . . . . . . .
4.2.4 Das Healthcare Information Framework . . . . . . . . . . . . . . . .
4.2.5 The Open Group Architectural Framework, Version 7 . . . . . . . .
4.3 Weitere Standards f¨
ur Integrationstechniken . . . . . . . . . . . . . . . . . .
4.4 Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen
4.4.1 Das Zachman-Rahmenwerk . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 Die Architektur integrierter Informationssysteme . . . . . . . . . . .
4.4.3 Enterprise Application Integration . . . . . . . . . . . . . . . . . . .
4.4.4 The Open Group Architectural Framework, Version 8 . . . . . . . .
4.4.5 Enterprise Application Planning . . . . . . . . . . . . . . . . . . . .
4.5 Rahmenwerke und Architekturstile . . . . . . . . . . . . . . . . . . . . . . .
4.6 Vergleichbarkeit von Architekturstandards . . . . . . . . . . . . . . . . . . .
5 Gesch¨
aftsprozessmodellierung — Eine Einf¨
uhrung
5.1 Vorbemerkungen . . . . . . . . . . . . . . . . .
5.2 Ereignisgesteuerte Prozessketten . . . . . . . .
5.3 Die Business Process Modeling Language . . .
5.4 Das Semantische Objektmodell . . . . . . . . .
II
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
. . 31
. . 32
. . 32
ISO 35
. . 40
. . 46
. . 49
. . 53
. . 54
. . 55
. . 56
. . 60
. . 65
. . 68
. . 72
. . 72
.
.
.
.
.
.
.
.
Architekturmodellierung
6 Einf¨
uhrung in das 3LGM2
6.1 Vorbemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Die Ebenen des 3LGM2 und ihre Hauptklassen . . . . . . . . . . . . . . .
6.2.1 Fachliche Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 Logische Werkzeugebene . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3 Physische Werkzeugebene . . . . . . . . . . . . . . . . . . . . . . .
6.3 Klassen f¨
ur die Integrationsmodellierung . . . . . . . . . . . . . . . . . . .
6.3.1 Klassen f¨
ur die Modellierung der Speicherung von Informationen .
¨
6.3.2 Klassen f¨
ur die Modellierung der Ubermittlung
von Informationen
6.4
6.5
IV
.
.
.
.
.
.
.
.
.
.
.
.
Prozessmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Das 3LGM2 und Architekturstile . . . . . . . . . . . . . . . . . . . . . . . .
24
28
28
28
30
77
77
77
79
81
85
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
87
87
87
88
88
92
92
92
94
95
95
Inhaltsverzeichnis
¨
7 Flexible Architekturmodellierung — Uberarbeitung
des 3LGM2
7.1 Begriffe f¨
ur die Modellierung von Komponenten auf der Basis des 3LGM2
¨
7.2 Uberarbeitung
des 3LGM2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1 Ereignistypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.2 Schnittstellen und Operationen . . . . . . . . . . . . . . . . . . . .
7.3 Transformation von Nachrichtentypen . . . . . . . . . . . . . . . . . . . .
7.4 Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.1 Spezifikationen f¨
ur Dienste . . . . . . . . . . . . . . . . . . . . . .
7.4.2 Modellierung von Diensten mit dem 3LGM2 . . . . . . . . . . . . .
7.5 Kommunikationsverbindungen . . . . . . . . . . . . . . . . . . . . . . . . .
7.6 Beispiele f¨
ur die Modellierung verschiedener Architekturstile . . . . . . . .
7.6.1 Modellierung von HISA-basierten Architekturen . . . . . . . . . .
7.6.2 Modellierung von OMA-basierten Architekturen . . . . . . . . . .
7.6.3 Modellierung von Kommunikationsserver-basierten Architekturen .
7.7 Einf¨
uhrung der Klasse Begriffssystem . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
99
99
99
102
105
105
105
107
107
108
108
110
111
113
III Architekturbewertung
117
8 Theoretische Vorbereitung der Integrationsbewertung
8.1 Vorbemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Die Interpretation von Elementhierarchien . . . . . . . . . . . . . . . . . . . . .
8.3 Mengen f¨
ur Klassen des 3LGM2A . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4 Pr¨
adikate zu Assoziationsbeziehungen des 3LGM2A . . . . . . . . . . . . . . . .
8.5 Zusammengesetzte Pr¨
adikate f¨
ur die Unterst¨
utzung der Bewertung . . . . . . .
8.5.1 Die Pr¨
adikate ben¨
otigt und unterst¨
utzt . . . . . . . . . . . . . . . . . .
8.5.2 Das Pr¨
adikat wird angewendet auf . . . . . . . . . . . . . . . . . . . . .
8.5.3 Pr¨
adikate f¨
ur die Analyse von Kommunikation . . . . . . . . . . . . . .
8.6 Formalisierung von Kommunikationsverbindungen . . . . . . . . . . . . . . . .
8.6.1 Kommunikationsverbindungen als Folgen von Kommunikationsbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6.2 Vermittlung und Vermittlungstiefe . . . . . . . . . . . . . . . . . . . . .
119
119
119
120
121
122
122
123
124
126
9 Die
9.1
9.2
9.3
129
129
130
133
133
134
136
136
138
140
140
140
142
143
Erf¨
ullung von Integrationsanforderungen
Mengen von Anwendungsbausteinen: Dom¨
anen . . . . . . . . . . .
Ein Anwendungsszenario . . . . . . . . . . . . . . . . . . . . . . . .
Anforderungsdom¨
anen . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.1 Datendom¨
anen . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.2 Funktionale Dom¨
anen . . . . . . . . . . . . . . . . . . . . .
9.3.3 Semantische Dom¨
anen . . . . . . . . . . . . . . . . . . . . .
9.3.4 Kontextdom¨
anen . . . . . . . . . . . . . . . . . . . . . . . .
9.3.5 Pr¨
asentationsdom¨
anen . . . . . . . . . . . . . . . . . . . . .
9.3.6 Zugriffsdom¨
anen . . . . . . . . . . . . . . . . . . . . . . . .
9.4 Kommunikationsdom¨
anen . . . . . . . . . . . . . . . . . . . . . . .
¨
9.4.1 Dom¨
anen f¨
ur die Ubermittlung
von Informationen . . . . .
9.4.2 Dom¨
anen f¨
ur den Aufruf von Funktionalit¨
at . . . . . . . . .
9.5 Anwendung: Pr¨
ufung der Erf¨
ullung von Integrationsanforderungen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
126
126
V
Inhaltsverzeichnis
9.5.1
9.5.2
9.5.3
9.5.4
9.5.5
9.5.6
.
.
.
.
.
.
143
145
147
150
152
152
10 Abh¨
angigkeit von Anwendungsbausteinen
10.1 Vorbemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Informationale und funktionale Abh¨
angigkeit . . . . . . . . . . . . . . . . . . .
10.2.1 Der informationale Abh¨
angigkeitsgrad . . . . . . . . . . . . . . . . . . .
10.2.2 Der funktionale Abh¨
angigkeitsgrad . . . . . . . . . . . . . . . . . . . . .
10.3 Ausf¨
uhrungsabh¨
angigkeit, transaktionale Abh¨
angigkeit und Transaktionsst¨
arke
10.3.1 Die Ausf¨
uhrungsabh¨
angigkeit . . . . . . . . . . . . . . . . . . . . . . . .
10.3.2 Die transaktionale Abh¨
angigkeit . . . . . . . . . . . . . . . . . . . . . .
10.3.3 Die Transaktionsst¨
arke einer Transaktionsausf¨
uhrung . . . . . . . . . .
10.3.4 Kategorien von Transaktionsausf¨
uhrungen . . . . . . . . . . . . . . . . .
10.4 Ein Anwendungsszenario aus dem Universit¨
atsklinikum Leipzig . . . . . . . . .
10.4.1 Vorstellung des Anwendungsszenarios . . . . . . . . . . . . . . . . . . .
10.4.2 Kennzahlen zur Abh¨
angigkeit f¨
ur das Anwendungsszenario . . . . . . .
157
157
159
159
159
160
160
161
162
162
163
163
167
11 Heterogenit¨
atsbewertung von Kommunikationsverbindungen
11.1 Vorbemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2 Der absolute Heterogenit¨
atsgrad von Kommunikationsverbindungen . . . . . .
11.2.1 Der absolute Heterogenit¨
atsgrad von zwei Kommunikationsverbindungen
11.2.2 Der absolute Heterogenit¨
atsgrad von n Kommunikationsverbindungen .
11.2.3 Interpretation des absoluten Heterogenit¨
atsgrades . . . . . . . . . . . .
11.2.4 Problematik der Anwendung des Heterogenit¨
atsgrades . . . . . . . . . .
11.3 Der relative Heterogenit¨
atsgrad von Kommunikationsverbindungen . . . . . . .
11.3.1 Der relative Heterogenit¨
atsgrad . . . . . . . . . . . . . . . . . . . . . . .
11.3.2 Interpretation des relativen Heterogenit¨
atsgrades . . . . . . . . . . . . .
11.4 Der kostenbewertete Heterogenit¨
atsgrad von Kommunikationsverbindungen . .
11.4.1 Kosten von Kommunikationsverbindungen . . . . . . . . . . . . . . . . .
11.4.2 Der kostenbewertete Heterogenit¨
atsgrad . . . . . . . . . . . . . . . . . .
11.4.3 Interpretation des kostenbewerteten Heterogenit¨
atsgrades . . . . . . . .
11.4.4 Bemerkungen zum kostenbewerteten Heterogenit¨
atsgrad . . . . . . . . .
11.5 Ein Anwendungsszenario aus dem Universit¨
atsklinikum Leipzig . . . . . . . . .
11.5.1 Ermittlung der Kommunikationsverbindungen als Folgen von Kommunikationsbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5.2 Kennzahlen zur Heterogenit¨
at f¨
ur das Anwendungsszenario . . . . . . .
171
171
171
171
177
178
178
179
179
180
181
181
181
182
183
184
Z Abschluss
Z.1 Vorbemerkungen . . . . .
Z.2 Beantwortung der Fragen
Z.2.1 Fragen zu Ziel Z1 .
Z.2.2 Fragen zu Ziel Z2 .
Z.2.3 Fragen zu Ziel Z3 .
187
187
187
187
190
192
VI
Pr¨
ufung
Pr¨
ufung
Pr¨
ufung
Pr¨
ufung
Pr¨
ufung
Pr¨
ufung
auf
auf
auf
auf
auf
auf
realisierte
realisierte
realisierte
realisierte
realisierte
realisierte
.
.
.
.
.
.
.
.
.
.
Datenintegration . . . .
funktionale Integration .
semantische Integration
Kontextintegration . . .
Pr¨
asentationsintegration
Zugriffsintegration . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
184
184
Inhaltsverzeichnis
Z.2.4 Fragen zu Ziel Z4 . . . . . . . . . . . . . . . . . . . . .
Z.3 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Z.3.1 Kommentierung der Ergebnisse . . . . . . . . . . . . .
Z.3.2 Erf¨
ullung der Ziele . . . . . . . . . . . . . . . . . . . .
Z.4 Potential f¨
ur Evaluationen und f¨
ur weiterf¨
uhrende Forschung
Anhang A
Anhang B
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
193
196
196
197
198
Anforderungskatalog f¨
ur die Informationsverarbeitung im Krankenhaus
(Auszug)
i
UML-Diagramme f¨
ur die Ebenen des 3LGM2A
v
Literaturverzeichnis
ix
Stichwortverzeichnis
xv
VII
Inhaltsverzeichnis
VIII
Kastenverzeichnis
2.1 Grundbegriffe (1): Informationen, Daten, Wissen . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Grundbegriffe (2): Informationssystem, Anwendungssystem, Integration . . . . . . . . . . . .
11
12
2.3 Exkurs zur semantischen Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1 Grundbegriffe (3): Definitionen f¨
ur Architektur . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Ausz¨
uge aus ISO/IEC 10746-2 (RM-ODP Foundations) . . . . . . . . . . . . . . . . . . . . .
21
23
3.3 Grundbegriffe (4) . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Grundbegriffe (5): Modelle und Referenzmodelle . . .
¨
4.1 Uberblick
u
¨ ber ISO-Standards zum RM-ODP . . . . . . . . .
¨
4.2 Uberblick
u
¨ ber ISO-Standards zum RM-ODP (Fortsetzung) .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
26
29
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
36
37
4.3 Erg¨anzende Standards zum RM-ODP: Spezifikation der in ISO/IEC 10746-3 vorgesehenen
Trading Function in Standard ISO/IEC 13235-1 (Ausz¨
uge) . . . . . . . . . . . . . . . . . . .
¨
4.4 Uberblick u
¨ ber OMG-Standards zur Architekturentwicklung . . . . . . . . . . . . . . . . . .
4.5 Beispiele f¨
ur Methoden zur Datensicht und zur Steuerungssicht der ARIS . . . . . . . . . . .
4.6 Schritte der EAP-Phasen und Beispiele f¨
ur zugeh¨orige
Aufgaben und Richtlinien . . . . . . . . . . . . . . . . .
4.7 Schritte der EAP-Phasen und Beispiele f¨
ur zugeh¨orige
Aufgaben und Richtlinien (Fortsetzung 1) . . . . . . . .
4.8 Schritte der EAP-Phasen und Beispiele f¨
ur zugeh¨orige
Aufgaben und Richtlinien (Fortsetzung 2) . . . . . . . .
7.1 Das Weglassen der Konfigurationen im 3LGM2A . . . .
Gegenst¨ande,
. . . . . . . .
Gegenst¨ande,
. . . . . . . .
Gegenst¨ande,
. . . . . . . .
. . . . . . . .
39
45
58
erwartete Ergebnisse,
. . . . . . . . . . . . . 70
erwartete Ergebnisse,
. . . . . . . . . . . . . 71
erwartete Ergebnisse,
. . . . . . . . . . . . . 72
. . . . . . . . . . . . . 104
9.1 Ereignistypen und Kommunikationsdom¨anen . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
11.1 Exkurs: Ausrichtung von Symbolsequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
IX
Abbildungsverzeichnis
1.1 Dimensionen der Qualit¨at von Informationssystemen (Quelle: [Stylianou and Kumar
2000], S. 100, Abb. 1, S. 103, Tab. 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1 IT-Infrastruktur-Integrationsprofile des IHE IT Infrastructure Technical Framework, Vol.
1 (Quelle: [HIMSS/RSNA 2003a], Figure 2-1, S. 10) . . . . . . . . . . . . . . . . . . .
2.2 Drei parallel genutzte Anwendungssysteme: ein Stationsmanagementsystem, ein OP-Dokumentationssystem und der Intranet-Server des Zentrallabors (Quelle: Bildschirmfoto
von einem PC am UKL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.1 Ein Komponententyp (a), ein Konnektorentyp (b) und eine Konfiguration (c) (Quelle
[Abowd et al. 1995], S. 329-331, Abb. 3 - Abb. 5) . . . . . . . . . . . . . . . . . . . . .
25
4.1 OSI-Referenzmodell (Quelle: [ISO/IEC JTC 1 1996c], S. 28) . . . . . . . . . . . . . . .
¨
4.2 Ubersichtsgrafik
zum generischen Schichtenkonzept (a) und Kommunikation von Einheiten der Schicht N + 1 u
¨ ber die Schicht N (b) (Quelle [ISO/IEC JTC 1 1996c], S. 7-8,
Figure 3 und Figure 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 OSI- und TCP/IP-Schichtenmodelle (nach [Washburn and Evans 1994], S. 9, 157) . .
4.4 Das Object Management Architecture Reference Model (Quelle: [OMG 1997], Abb. 4-1)
4.5 Das Model Driven Architecture Pattern (a) (Quelle: [OMG 2003b], Abb. 2-2) und generische Unterscheidung von Sichtweisen auf Plattformen (b) (Quelle: [OMG 2003b],
Abb. 6-6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6 Die Schichten der Architektur von Informationssystemen im Gesundheitswesen (Quelle:
[CEN TC251 1997], Abbildung 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 Informationsmodell f¨
ur die Subject of Care Healthcare Common Services (a) und funktionale Spezifikation (b) (Quelle: [CEN TC251 1997], S. 15) . . . . . . . . . . . . . . .
4.8 TOGAF und seine Beziehungen zu anderen US-amerikanischen Rahmenwerken (Quelle:
unbekannt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.9 Die Phasen der TOGAF Architecture Development Method und die Schritte der Phase
C (Quelle: [The Open Group 2001], Part II, Introduction, Figure 2) . . . . . . . . . .
4.10 Einfache (a) und detailliertere (b) Grafik zum TOGAF TRM (Quellen: [The Open
Group 2001], Part III, High-level Breakdown, Figure 1 und Part III, TRM in Detail,
Figure 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.11 Das Zachman-Rahmenwerk f¨
ur Informationssystemarchitektur (Quelle: [Zachman 1999])
4.12 Das ARIS-Haus (Quelle: [Scheer 1998b], S. 46, Abbildung 20) . . . . . . . . . . . . . .
4.13 Metamodell der Fachkonzeptebene der Funktionssicht (Ausschnitt, Quelle: [Scheer 1998a],
S. 38, Abbildung 33) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.14 Das ARIS-Phasenmodell (Quelle: [Scheer 1998b], S. 39, Abbildung 16) . . . . . . . . .
4.15 Vertikale Fragmentierung von Informationssystemen und horizontale Integration (Quelle:
[Hasselbring 2000], S. 34-35, Figure 1 und Figure 2) . . . . . . . . . . . . . . . . . . .
4.16 Unterscheidung von Integrationsebenen in [Hasselbring 2000] (a) sowie von EAI-Ebenen
in [Linthicum 2000b] (b) und in [Longo 2001] (c) . . . . . . . . . . . . . . . . . . . .
4.17 Einfaches Architektur-Referenzmodell f¨
ur EAI (Quelle: [Schmidt 2002]) . . . . . . . . .
4.18 EAI-Architekturmuster (Quelle: [Lutz 2000]) . . . . . . . . . . . . . . . . . . . . . . . .
4.19 Die Phasen der TOGAF Architecture Development Method und die Schritte der Phase
D (Quelle: [The Open Group 2003], Part II, Introduction, Figure 2) . . . . . . . . . .
13
32
34
34
41
44
47
48
49
51
52
55
57
57
59
60
61
63
64
65
XI
Abbildungsverzeichnis
4.20 Architekturkontinuum (a) und L¨osungskontinuum (b) in TOGAF, Version 8 (Quelle:
[The Open Group 2003], Part III, Enterprise Continuum in Detail, Architecture Continuum, Figure 1 und Solutions Continuum, Figure 3) . . . . . . . . . . . . . . . . . . .
4.21 TOGAF TRM in TOGAF, Version 8, (a und b) und Ableitung der Elemente des TOGAF
III-RM aus dem TOGAF TRM (c und d) (Quellen: [The Open Group 2003], Part III,
Foundation Architecture: Technical Reference Model, High-level Breakdown, Figure 1,
und TRM in Detail, Figure 1, [The Open Group 2003], Part III, Integrated Information
Infrastructure Reference Model, High-Level View, Figure 2b und Figure 3) . . . . . . .
4.22 Phasen des Enterprise Architecture Planning (Quelle: [Spewak and Hill 1992], S. 13,
Figure 1.7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Beispiel f¨
ur eine EPK (Quelle: [Langner et al. 1997], S. 481, Abb. 1) . . . . . . . . . .
5.2 Beispiel f¨
ur eine Prozessbeschreibung mit der BPML; die mit wsdl“ beginnenden Defini”
tionen sind WSDL-Definitionen f¨
ur Dienste (Quelle: [BPMI BPML WG 2002], S. 67-70,
Beispiel 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Beispiel f¨
ur eine mit der BPMN erstellte Prozessbeschreibung (Quelle: [BPMI Notation
WG 2004], S. 139, Abb. 87) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Ebenen der Unternehmensarchitektur im SOM-Ansatz (Quelle: [Ferstl and Sinz 1995],
S. 212, Abb. 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Metamodell f¨
ur die Gesch¨aftsprozessmodellierung im SOM-Ansatz (Quelle: [Ferstl and
Sinz 1995], S. 216, Abb. 7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6 Beispiel f¨
ur ein Interaktionsmodell (a) und ein Vorgangs-Ereignis-Modell (b) (Quelle:
[Ferstl and Sinz 1995], S. 218-219, Abb. 10 u. 12) . . . . . . . . . . . . . . . . . . . .
6.1 Spezifikationen der fachlichen Ebene des 3LGM2 mit der UML (vgl. [Winter et al.
2003], S. 546, Abb. 1) (a) und Auszug der fachliche Ebene des Informationssystems des
UKL (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Spezifikationen der logischen Werkzeugebene des 3LGM2 mit der UML (vgl. [Winter
et al. 2003], S. 547, Abb. 3) (a) und Auszug der logischen Werkzeugebene des Informationssystems des UKL (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Spezifikationen der physischen Werkzeugebene des 3LGM2 mit der UML (vgl. [Winter et al. 2003], S. 548, Abb. 5) (a) und Auszug der physischen Werkzeugebene des
Informationssystems des UKL (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Auszug des Informationssystems des UKL in Drei-Ebenen-Darstellung . . . . . . . . . .
6.5 Kombinationen von Ereignistypen und Nachrichtentypen zur Beschreibung der Kommunikation zwischen den Anwendungsbausteinen Patientenverwaltungssystem und Kommunikationsserver am UKL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
¨
6.6 Ein Kommunikationsprozess zur Ubermittlung
von ADT-Informationen im Informationssystem des UKL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1 Fachliche Ebene des 3LGM2A ; hervorgehoben sind die u
¨ berarbeiteten Klassen. . . . . . .
7.2 Logische Werkzeugebene des 3LGM2A ; hervorgehoben sind die neu eingef¨
uhrte Klasse
Operation und die u
¨ berarbeiteten Assoziationsbeziehungen. . . . . . . . . . . . . . . .
¨
7.3 Eine Kommunikationsverbindung zur Ubertragung
von Falldaten im Informationssystem
des UKL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Eine einfache OMA-basierte Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 Eine einfache OMA-basierte Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6 Eine einfache Kommunikationsserverarchitektur . . . . . . . . . . . . . . . . . . . . . . .
7.7 Erweiterte fachliche Ebene des 3LGM2A ; hervorgehoben sind die neu eingef¨
uhrte Klasse
Begriffssystem und die zuvor in Abschnitt 7.2.1 u
¨ berarbeiteten Klassen. . . . . . . .
XII
66
67
69
78
80
81
82
83
84
89
90
91
93
95
96
101
103
108
109
111
112
113
Abbildungsverzeichnis
7.8 Beispiele f¨
ur die Zuordnung von Begriffssystemen zu greift_zu_auf-beziehungen: Bei
der Interpretation und Bearbeitung von Diagnosen und Prozeduren werden die Diagnosenklassifikation ICD10, die Prozedurenklassifikation OPS301 und das Abrechnungssystem DRG angewendet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.9 Erweiterte logische Werkzeugebene des 3LGM2A mit den Beziehungen der Klasse Begriffssystem zu den Klassen der logischen Werkzeugebene . . . . . . . . . . . . . . . 115
7.10 Physische Werkzeugebene des 3LGM2A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.1 Interpretation von ist_Teil_von-Beziehungen . . . . . . . . . . . . . . . . . . . . . . . 120
8.2 Beispiel f¨
ur eine Kommunikationsverbindung mit Vermittlungsbeziehungen . . . . . . . 127
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
9.10
9.11
9.12
9.13
9.14
9.15
9.16
Auszug aus der fachlichen Ebene des Informationssystems des UKL . . . . . . . . . . .
Ausz¨
uge aus der logischen Werkzeugebene des Informationssystems des UKL . . . . . .
Datendom¨ane des Objekttyps Fall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Funktionale Dom¨ane der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung . . . . . .
Zuordnung der Begriffssysteme DRG, ICD10 und OPS301 zu greift_zu_auf-Beziehungen (a) und semantische Dom¨anen der Begriffssysteme (b) . . . . . . . . . . . . .
Kontextdom¨ane des Objekttyps Fall und des physischen Datenverarbeitungsbausteines PC NCH 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pr¨asentationsdom¨ane des physischen Datenverarbeitungsbausteines PC NCH 15 .
¨
Ubermittlungsdom¨
ane des Objekttyps Fall, des Ereignistyps NP11I0 und des Anwendungsbausteines Patientenverwaltungssystem . . . . . . . . . . . . . . . . . . . . . . .
Aufrufdom¨ane der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung, des Ereignistyps DIAPROZ init und des Anwendungsbausteines Verschl¨
usselungssystem . . . . .
Vergleich der Datendom¨ane des Objekttyps Fall und des Ereignistyps NP11I0 (a)
¨
mit der Ubermittlungsdom¨
ane des Objekttyps Fall, des Ereignistyps NP11I0 und
des Anwendungsbausteines Patientenverwaltungssystem (b) . . . . . . . . . . . . . . .
Vergleich der funktionalen Dom¨ane der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung (a) mit der Aufrufdom¨ane der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung,
usselungssysdes Ereignistyps DIAPROZ init und des Anwendungsbausteines Verschl¨
tem (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
¨
Vergleich der semantischen Dom¨ane des Begriffssystems ICD10 (a) mit der Ubermittlungsdom¨ane desselben Begriffssystems, des Ereignistyps ICD neu und des Anwendungsbausteines Verschl¨
usselungssystem (b) . . . . . . . . . . . . . . . . . . . . . . .
Vergleich der semantischen Dom¨ane des Begriffssystems ICD10 (a) mit der Aufrufdom¨ane der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung, des Ereignistyps DIAPROZ init und des Anwendungsbausteines Verschl¨
usselungssystem (b) . . . . . . . . .
Vergleich der Kontextdom¨ane des Objekttyps Fall, des physischen Datenverarbeitungsbausteines PC NCH 15 und des Ereignistyps Kontextwechsel Fall (a) mit der
¨
Ubermittlungsdom¨
ane des Objekttyps Fall, des Ereignistyps Kontextwechsel Fall und
des Anwendungsbausteines KDMS-IS-H*MED (b) . . . . . . . . . . . . . . . . . . . .
Vergleich der Zugriffsdom¨ane des physischen Datenverarbeitungsbausteines PC NCH
¨
15 (a) mit der Ubermittlungsdom¨
ane des Objekttyps Mitarbeiter des Pflegedienstes, des
Ereignistyps ZUGR update und des Anwendungsbausteines R/3-basierte Anwendungen (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vergleich der Zugriffsdom¨ane des physischen Datenverarbeitungsbausteines PC NCH
15 (a) mit der Aufrufdom¨ane der Aufgabe Rechtepr¨
ufung MRZ, des Ereignistyps LOGIN BBS und des Anwendungsbausteines LDAP-Benutzerverzeichnissystem (b) . . . .
130
132
134
135
137
138
139
141
142
144
146
148
149
151
153
155
10.1 L¨osungsspektrum zur Unterst¨
utzung heterogener Datenbanken (Quelle: [Rahm 1994],
Abschnitt 10.4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
XIII
Abbildungsverzeichnis
10.2 Alte Architektur im Anwendungsszenario aus dem UKL; hervorgehoben sind die Anwendungsbausteine der Datendom¨ane des Objekttyps Fall, des Ereignistyps NP11I0
und des Anwendungsbausteines Patientenverwaltungssystem . . . . . . . . . . . . . . . 164
10.3 Geplante Architektur im Anwendungsszenario aus dem UKL; hervorgehoben sind die Anwendungsbausteine der Datendom¨ane des Objekttyps Fall, des Ereignistyps NP11I0
und Anwendungsbausteines Patientenverwaltungssystem . . . . . . . . . . . . . . . . . 165
10.4 Anwendungsszenario aus dem UKL mit Kommunikationsserver (a) und mit ORB (b);
hervorgehoben sind die Kommunikationsverbindungen zur Verteilung der Falldaten . . 166
11.1 Ausrichtung von zwei Kommunikationsverbindungen . . . . . . . . . . . . . . . . . . . .
11.2 Berechnung des Gleichheitswertes p von zwei ausgerichteten Kommunikationsverbindungen mit Vermittlungsverbindungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3 Berechnung des Gleichheitswertes p von drei Kommunikationsverbindungen . . . . . . .
11.4 Anwendungsszenario aus dem UKL mit Kommunikationsserver (a) und mit ORB (b);
hervorgehoben sind die Kommunikationsverbindungen zur Verteilung der Falldaten . .
11.5 Ausgerichtete Kommunikationsverbindungen des Anwendungsszenarios; Berechnung der
absoluten und der relativen Gleichheitswerte . . . . . . . . . . . . . . . . . . . . . . . .
XIV
174
175
177
185
186
Tabellenverzeichnis
3.1 Beispiele f¨
ur Architekturstile (zusammengestellt aus [Shaw and Garlan 1996], Abschnitte 2.2-2.5, S. 21-25) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.1 Zuordnung von RM-ODP-Sichtweisen zu MDA-Sichtweisen (Quelle: [OMG 2003b], S. 3-1
- 3-2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
¨
4.2 Ubersicht
u
¨ ber Rahmenwerke zu Informationssystemarchitekturen (Teil 1) . . . . . . . .
¨
4.3 Ubersicht
u
¨ ber Rahmenwerke zu Informationssystemarchitekturen (Teil 2) . . . . . . . .
43
74
75
6.1 Beispiele f¨
ur Ereignistypen im Kommunikationsstandard HL7 (Quelle: [HL7 1999]) . .
94
7.1 Beispiele f¨
ur ¨aquivalente Ereignistypen in den Kommunikationsstandards HL7 und
SAP-HCM (vgl. Tabelle 6.1; Quellen: [HL7 1999] und [SAP 2005]) . . . . . . . . . . . 102
9.1 Elemente des Beispielmodells des Informationssystems des UKL . . . . . . . . . . . . . . 131
9.2 Elemente des Beispielmodells des Informationssystems des UKL (Fortsetzung 2) . . . . . 133
XV
A Einleitung
In vielen Krankenh¨
ausern werden zur Zeit in großer Breite rechnerunterst¨
utzte Anwendungssysteme eingef¨
uhrt. Sie dienen u. a. der Verschl¨
usselung von Diagnosen und Prozeduren, der
OP-Dokumentation, der Arztbriefschreibung oder dem Erstellen und Verteilen von Befunden
und Bildern.
Die damit enstehende nahezu fl¨
achendeckende Rechnerausstattung l¨
asst in vielen medizinischen Abteilungen eines Krankenhauses Forderungen nach elektronischer Verf¨
ugbarkeit von
Informationen anderer Abteilungen entstehen. Einzelne rechnerunterst¨
utzte Insell¨
osungen sollen also miteinander verkn¨
upft werden. Beispielsweise fordern Stations¨
arzte und Pflegekr¨
afte
M¨oglichkeiten der Einsicht in Laborbefunde von Rechnern auf der Station aus. Dazu muss der
Zugriff auf das Befundungssystem des Labors bereitgestellt werden, oder die Laborbefunde
m¨
ussen automatisch in ein auf den Stationsrechnern verf¨
ugbares Anwendungssystem u
¨ bertragen werden.
Verwaltungsabteilungen, wie die Patientenverwaltung oder das Controlling, fordern die elektronische Verf¨
ugbarkeit von Daten, z. B. zur Weiterverarbeitung bei der Erstellung von Rechnungen und Statistiken. So werden seit dem Jahr 2000 große Anstrengungen im Zusammenhang
¨
mit der elektronischen Ubermittlung
von Diagnose- und Prozedurdaten f¨
ur die Patientenabrechnung und f¨
ur die Vorbereitung der Einf¨
uhrung der Diagnosis Related Groups (DRGs)
unternommen.
Durch die Verf¨
ugbarkeit abteilungsspezifischer Anwendungssysteme unterschiedlicher Hersteller sind die Informationsmanager von Krankenh¨
ausern oft einer Vielzahl von Informationssystemkomponenten gegen¨
ubergestellt. Diese unterscheiden sich hinsichtlich der zugrunde
liegenden Implementierungskonzepte, der verwendeten Datenstrukturen oder der Gestaltung
der Benutzungsschnittstellen. Trotzdem sollen sie aber m¨
oglichst ohne zus¨
atzliche Handarbeit
miteinander kommunizieren, um den Anwendern die Belastung des Abschreibens, der mehrfachen Anmeldung usw. zu ersparen.
A.1 Gegenstand, Problematik, Motivation
A.1.1 Gegenstand
Hauptgegenstand der Arbeit sind Krankenhausinformationssysteme. Die in dieser Arbeit entwickelten L¨
osungsans¨
atze sind nicht grunds¨
atzlich auf Krankenhausinformationssysteme beschr¨
ankt, aber durch die Arbeit mit und in diesen Systemen gepr¨
agt.
Das Management komplexer Informationssysteme erfordert umfangreiche Kenntnisse u
¨ ber
die Informationssystemkomponenten und ihre Integration. Diese Arbeit entwickelt eine Modellierungsvorschrift f¨
ur die Integration. Mit der Vorschrift soll es gelingen, Integrationsanforderungen verschiedener Kategorien, z. B.
– Datenintegration,
– funktionale Integration oder
1
A Einleitung
– Kontextintegration,
verschiedene Integrationstechniken, z. B.
–
–
–
–
nachrichtenbasierte Kommunikation,
Remote Function Call,
Object Request Broker oder
Kontextsynchronisierung,
unter Ber¨
ucksichtigung verschiedener durch Architekturstandards vorgegebener Architekturstile, z. B.
– Store-&-Forward-Architektur,
– Object Management Architecture oder
– Healthcare Information Systems Architecture
formal zu beschreiben und leicht verst¨
andlich in Texten oder Grafiken darzustellen.
Die Modellierungsvorschrift wird nicht unabh¨
angig von anderen Ans¨
atzen entworfen, sondern
2
als Erweiterung eines vorhandenen Metamodells, des 3LGM ([Winter et al. 2003]) zum
3LGM2A . Das 3LGM2 definiert drei Ebenen mit verschiedenen Modellelementen, auf deren
Basis Referenzmodelle und Modelle bestehender Informationssysteme erstellt werden k¨
onnen.
Auf der Basis der Modellierungsvorschrift werden Ans¨
atze f¨
ur die Bewertung der Integration
von Anwendungssystemen entwickelt. Mit diesen Ans¨
atzen soll erm¨
oglicht werden
– die Erf¨
ullung von Integrationsanforderungen formal zu u
ufen und
¨ berpr¨
– die Architektur des Informationssystems hinsichtlich der Abh¨
angigkeit von Anwendungssystemen sowie der Heterogenit¨
at der eingesetzten Integrationstechniken quantitativ zu
bewerten.
A.1.2 Problematik
Kenntnisse u
¨ ber die Integration von Informationssystemkomponenten sind oft nicht oder nicht
zusammenh¨
angend dokumentiert. Dadurch ist u. a. der Einarbeitungsaufwand bei Mitarbeiterwechseln sehr hoch, oder bei Problemen m¨
ussen Informationen u
¨ ber die Integration aufwendig
zusammengestellt werden.
Das Informationsmanagement wird weiterhin dadurch erschwert, dass
– Dokumentationen von Informationssystemkomponenten von den Herstellern bzw. Lieferanten auf spezielle, hauseigene Weise erstellt werden,
– Anforderungen an Informationssystemkomponenten von den Kunden, d. h. den Krankenh¨
ausern, auf spezielle, hauseigene Weise erstellt werden und
– Dokumentationen moderner Integrationstechniken und -standards durch die herausgebenden Organisationen auf spezielle Weise erstellt werden.
Dadurch ist es schwer, die Vor- und Nachteile der Anwendung bestimmter Techniken und
Standards f¨
ur die Integration einzusch¨
atzen und Entscheidungen f¨
ur oder gegen die Einf¨
uhrung
oder Abl¨
osung von Komponenten verschiedener Hersteller zu treffen.
Diese Arbeit soll zur L¨
osung folgender Probleme beitragen:
Problem P1 Ein Vergleich von Architekturstandards, die verschiedenen Integrationstechniken zugrunde liegen, ist ohne ausf¨
uhrliche Auseinandersetzung mit diesen
2
A.2 Zielsetzung und Fragestellung
Standards kaum m¨
oglich.
Problem P2 F¨
ur das Dokumentieren bzw. das Modellieren von Integrationsanforderungen
und Integrationstechniken werden oft unterschiedliche Methoden und Vorgehensweisen gew¨
ahlt. Dadurch k¨
onnen die betreffenden Dokumente bzw.
Modelle nur schwer verglichen werden.
Problem P3 Auswahlentscheidungen f¨
ur oder gegen bestimmte Integrationstechniken k¨
onnen oft nicht oder nur schwer hinsichtlich der Erf¨
ullung von Integrationsanforderungen oder der Beeinflussung der Integrationsinfrastruktur getroffen
werden.
Problem P4 Mit vorhandenen Werkzeugen zur Informationssystemmodellierung k¨
onnen
Integrationsanforderungen und ihre Erf¨
ullung nur schwer modelliert und bewertet werden.
A.1.3 Motivation
Am Institut f¨
ur Medizinische Informatik, Statistik und Epidemiologie (IMISE) der Universit¨
at
Leipzig wird das in Abschnitt A.1 genannte Metamodell 3LGM2 weiterentwickelt. Wesentliche
Fragen der Weiterentwicklung des Modells betreffen die Integration von Informationssystemkomponenten. Diese Arbeit soll zu dieser Weiterentwicklung beitragen.
Gleichzeitig ist der Autor dieser Arbeit in Projekten zur Integration von Anwendungssystemen am Universit¨
atsklinikum Leipzig (UKL) t¨
atig. Innerhalb der Projekte treten im Zusammenhang mit Integrationsfragestellungen immer wieder Probleme auf, die sich unter den in Abschnitt A.1.2 genannten Problemen zusammenfassen lassen. Eine Unterst¨
utzung der Analyse
und Planung der Integrationsinfrastruktur k¨
onnte die Durchf¨
uhrung von Integrationsprojekten
am UKL und an anderen Klinika erleichtern. Die in den Projekten gesammelten Erfahrungen
k¨
onnen bei der Entwicklung von L¨
osungsans¨
atzen helfen.
A.2 Zielsetzung und Fragestellung
A.2.1 Zielsetzung
Diese Arbeit hat die folgenden Ziele:
Ziel Z1 (zu P1 - P3) Es soll dargestellt werden, welche Anforderungen bzgl. der Integration Integrationsanforderung von Informationssystemkomponenten typischerweise
in Krankenh¨
ausern gestellt werden und welche Techniken zu ihrer Erf¨
ullung verwendet werden k¨
onnen.
¨
Ziel Z2 (zu P1) Es soll eine vergleichende Ubersicht
u
¨ ber Architekturstandards erstellt
werden.
¨
Ziel Z3 (zu P2) Es soll eine Uberarbeitung
des 3LGM2 entworfen werden, welche die Modellierung der Erf¨
ullung von Integrationsanforderungen und die Bewertung der
Verwendung unterschiedlicher Integrationstechniken erlaubt. Dabei sollen vorhandene Architekturstandards ber¨
ucksichtigt werden.
Ziel Z4 (zu P3) Es soll mit Hilfe des u
¨ berarbeiteten 3LGM2 untersucht werden, ob verschiedene Integrationstechniken ausgetauscht werden k¨
onnen, ohne dass dabei Einbußen an Funktionalit¨
at entstehen.
3
A Einleitung
Zu Problem P4 ist kein spezielles Ziel angegeben, da die Werkzeugentwicklung in dieser Arbeit nicht behandelt wird. Mit dem in [Wendt et al. 2004] beschriebenen Werkzeug 3LGM2 Baukasten k¨
onnen 3LGM2 -konforme Modelle erstellt und analysiert werden k¨
onnen. Es kann
als Grundlage f¨
ur ein Modellierungswerkzeug dienen, das der in dieser Arbeit vorgenommenen
¨
Uberarbeitung
des 3LGM2 entspricht und die Anwendung der ebenfalls in dieser Arbeit entwickelten Bewertungsans¨
atze erm¨
oglicht. Die Ergebnisse dieser Arbeit k¨
onnen als Spezifikation
f¨
ur die Werkzeug(weiter)entwicklung verwendet werden.
A.2.2 Fragestellung
Um die Ziele aus Abschnitt A.2.1 zu erf¨
ullen, sollen u. a. die folgenden Fragen beantwortet
werden:
1. Fragen zu Ziel Z1:
F1.1 Welche Anforderungen werden an die Integration von Informationssystemkomponenten gestellt?
F1.2 Welche Techniken k¨
onnen zur Erf¨
ullung der Integrationsanforderungen verwendet
werden und welche Vor- bzw. Nachteile haben sie?
2. Fragen zu Ziel Z2:
F2.1 Welche bekannten Architekturstandards gibt es und welche Charakteristika haben
sie?
F2.2 Wie stehen die Integrationsanforderungen mit den Architekturstandards in Beziehung?
F2.3 Welchen Integrationstechniken liegen die Architekturstandards zugrunde?
3. Fragen zu Ziel Z3:
F3.1 Wie stehen die in Frage F2.1 genannten Architekturstandards mit dem 3LGM2 in
Beziehung?
F3.2 Wie muss das 3LGM2 u
¨ berarbeitet werden, um die in Frage F1.1 genannten Integrationsanforderungen modellieren zu k¨
onnen?
F3.3 Wie muss das 3LGM2 u
¨ berarbeitet werden, um die in Frage F1.2 genannten Integrationstechniken modellieren sowie Vor- und Nachteile bestimmen zu k¨
onnen?
4. Fragen zu Ziel Z4:
F4.1 Welche Gemeinsamkeiten und Unterschiede bestehen zwischen den in Frage F2.1
genannten Architekturstandards?
F4.2 Wie k¨
onnen die in Frage F2.3 genannten Integrationstechniken ausgetauscht werden
und welche Einbußen oder Gewinne an Funktionalit¨
at entstehen dabei?
4
Teil I
Grundlagen
5
1 Bewertung der Integration: Ziel und Grundannahmen
Die Bewertung des Einsatzes bestimmter Integrationstechniken nimmt, nach ausf¨
uhrlicher Vorbereitung, einen großen Teil der vorliegenden Arbeit ein. Die im Abschnitt A.2.2 der Einleitung
genannten Fragen, insbesondere die Fragen F1.2, F3.3 und F4.2, f¨
uhren zur Er¨
orterung der Bewertungsthematik. Bevor in den weiteren Kapiteln von Teil I und im Teil II Anworten zu den
u
ur die Bewertungsans¨
atze von
¨ brigen Fragen und wesentliche Grundlagen und Vorbereitungen f¨
Teil III erarbeitet werden, beschreibt dieses Kapitel das Bewertungsziel und Grundannahmen
f¨
ur die Bewertung. Diese Ausf¨
uhrungen leiten die weiteren Kapitel dieser Arbeit.
1.1 Bewertungsziel
F¨
ur die Bewertung von Informationssystemen oder einzelnen Komponenten werden oft betriebswirtschaftliche Kriterien formuliert. Als Ziel von Evaluationen wird z. B. der Kennt¨
nisgewinn u
im Kosten-Nutzen-Verh¨
altnis genannt. Kosten werden dann
¨ ber die Anderungen
z. B. u
atekosten, Materialverbr¨
auche, Behandlungszeiten, Kosten von Nebenwirkungs¨ ber Ger¨
behandlungen usw. quantifiziert.
Auch andere Evaluationsziele, die die Behandlungsqualit¨
at und die Zufriedenheit von Patienten, aber auch die Zufriedenheit des medizinischen Personals in den Mittelpunkt stellen,
werden vermehrt gesetzt. Zugeh¨
orige Bewertungskriterien umfassen u. a. quantitative Elemente wie Wartezeiten, L¨
angen von Krankenhausaufenthalten, das Auftreten von Komplikationen
oder Nebenwirkungen, Zeiten f¨
ur die Bereitstellung von Akten, aber auch qualitative Elemente wie die subjektive Zufriedenheit von Patienten mit der Behandlung oder die subjektive
Bewertung der Benutzbarkeit von Anwendungssystemen durch Personal.
Die genannten Evaluationsziele und -kriterien sollen hier nicht in Frage gestellt werden.
Der Schwerpunkt dieser Arbeit liegt jedoch
auf einem weiteren, in der Literatur bisher
kaum diskutierten Evaluations- bzw. Bewertungsziel: der Bewertung der Architekturqualit¨
at eines Informationssystems.
Da die Architektur unmittelbar mit der Integration von Informationssystemkomponenten zusammenh¨
angt, kann man auch von Bewertung der Integrationsqualit¨
at sprechen.
Informationssystembewertung
f¨
ur das Informationsmanagement
Ziel
Bewertung der Architekturqualit¨
at (=Integrationsqualit¨
at) eines Informationssystems
Grundannahmen der Architekturbewertung
GA1: Bei der Bewertung der Architektur stehen folgende Fragen im Vordergrund:
– Welche Integrationsanforderungen bestehen?
– Sind die Integrationsanforderungen erf¨
ullt?
– Wie groß ist die Abh¨
angigkeit zwischen Anwendungssystemen?
– Wie komplex ist die Architektur des Informationssystems?
GA2: Mit der Anzahl unterschiedlicher Integrationstechniken steigt die Komplexit¨
at und sinkt die
Beherrschbarkeit eines Informationssystems.
¨
Uber
die bereits genannten Evaluationskriterien kann die Architektur eines Informationssystems mittelbar bewertet werden, u. a. hinsichtlich der Erf¨
ullung der Nutzeranforderungen.
Bisher sind jedoch f¨
ur das Informationsmanagement keine geeigneten unmittelbaren formalen
7
1 Bewertung der Integration: Ziel und Grundannahmen
Abbildung 1.1: Dimensionen der Qualit¨
at von Informationssystemen (Quelle: [Stylianou and Kumar 2000], S. 100,
Abb. 1, S. 103, Tab. 1)
Bewertungsans¨
atze f¨
ur die Erf¨
ullung von Nutzeranforderungen und und f¨
ur die Bewertung der
Komplexit¨
at und Wartbarkeit von Informationssystemen bekannt.
Die im Teil III dieser Arbeit entwickelten Bewertungsans¨
atze wurden f¨
ur das Management
von Informationssystemen entworfen. Sie sollen die strategische Bewertung und Planung von
Informationssystemen unterst¨
utzen, z. B. bei der Ermittlung unn¨
otiger Komplexit¨
at oder beim
Vergleich von alternativen L¨
osungsans¨
atzen. Spezielle technisch orientierte Bewertungsans¨
atze,
z. B. Quality of Service, werden nicht behandelt.
1.2 Grundannahmen der Architekturbewertung
¨
Ahnlich
mathematischen Axiomen, nur weniger formal, werden hier f¨
ur die Architekturbewertung Grundannahmen getroffen, auf deren Basis die Bewertungsans¨
atze der Kapitel 9 bis 11
entwickelt werden:
GA1: Bei der Bewertung der Architektur stehen folgende Fragen im Vordergrund:
– Welche Integrationsanforderungen bestehen?
– Sind die Integrationsanforderungen erf¨
ullt?
– Wie groß ist die Abh¨
angigkeit zwischen Anwendungssystemen und wo besteht
Potential zur Verringerung der Abh¨
angigkeit?
– Wie komplex ist die Architektur des Informationssystems und wo besteht Vereinfachungspotential?
GA2: Mit der Anzahl unterschiedlicher verwendeter Integrationstechniken steigt die Komplexit¨
at und sinkt die Beherrschbarkeit eines Informationssystems. Das gilt insbesondere dann, wenn mehrere Integrationstechniken zur Erf¨
ullung derselben Integrationsanforderung(en) angewendet werden.
Von den zur Grundannahme GA1 genannten Fragen, die bei der Architekturbewertung im
Vordergrund stehen, werden die ersten beiden hier ohne weitere Kommentierung als grundlegende Fragen angenommen.
8
1.2 Grundannahmen der Architekturbewertung
Mit den beiden anderen Fragen wird unterstellt, dass die Komplexit¨
at des Informationssystems im Mittelpunkt der unmittelbaren formalen Bewertung stehen sollte. Die Auswahl st¨
utzt
sich auf die immer wieder in der Informationsmanagementpraxis auftretende Forderung nach
einfachen Architekturen und Wiederverwendung von Integrationstechniken. In Arbeiten wie
[Clegg 2000] und [Hayne and Pollard 2000] wurden verschiedene Kriterien f¨
ur gutes Management, insbes. auch das Systemdesign, herausgearbeitet. Darin finden sich u. a. Forderungen
nach Vereinfachung:
Principle 11: Systems should be simple and make problems visible.“ ([Clegg 2000], S. 471)
”
A systems analyst at a large public transit company summarized as follows: ’We have a really mixed bag
”
of development tools at the moment. We go everywhere from COBOL and FORTRAN all the way up to
4GL’s such as PowerHouse and FoxPro. So we are trying to support too many different types of applications
and too many different languages.’“ ([Hayne and Pollard 2000], S. 78)
Beide zitierte Werke nennen auch andere Forderungen bzw. Kriterien. Viele davon beziehen
sich auf die Gestaltung von Prozessen im Informationsmanagement, z. B. auf die Ber¨
ucksichtigung sozialer Aspekte, das Projektmanagement oder die strategische Ausrichtung. Sie
sind ebenso wichtig, sollen hier aber nicht behandelt werden. Hier steht das Ergebnis von
Informationsmanagement-Projekten, d. h. der Zustand des Informationssystems, im Vordergrund, genauer: die Qualit¨
at der Architektur bzw. der Integration.
In [Stylianou and Kumar 2000] werden verschiedene Dimensionen bzw. Aspekte der Qualit¨at beschrieben. Bezogen auf diese Qualit¨
atsdimensionen behandelt die vorliegende Arbeit die
administrative Qualit¨
at (administrative quality) und die Betreuungsqualit¨
at (service quality)
(Abbildung 1.1).
Das 3LGM2 als Beschreibungssprache f¨
ur Informationssysteme
F¨
ur die Bewertung von Informationssystemen wird eine Erweiterung des Metamodells 3LGM2 ,
das in Kapitel 7 erarbeitete 3LGM2A , als Beschreibungssprache zugrunde gelegt. Informationen
u
ur die in dieser Arbeit erarbeiteten Bewertungsans¨
atze ben¨
otigt
¨ ber Informationssysteme, die f¨
2
uckt werden. Aus diesen prim¨
aren“ Informationen
werden, k¨
onnen mit dem 3LGMA ausgedr¨
”
k¨
onnen weitere Informationen zur Bewertung abgeleitet werden. Letzteres wird in den Kapiteln
von Teil III ausf¨
uhrlich beschrieben.
9
2 Integrationsanforderungen
2.1 Vorbereitung
Die in diesem Kapitel vorgestellten Kategorien von Integrationsanforderungen sind wichtige
Grundlage f¨
ur die Bewertung der Integration von Informationssystemkomponenten hinsichtlich der Erf¨
ullung von Integrationsanforderungen. Sie werden in vielen Kapiteln dieser Arbeit,
haupts¨
achlich jedoch im Kapitel 9, verwendet. Dort werden die Modellierung von Integrationsanforderungen und die Pr¨
ufung der Erf¨
ullung der Anforderungen behandelt.
Integrationsanforderungen werden in dieser Arbeit als Forderungen an die Leistungsf¨
ahigkeit bzw. Funktionalit¨
at aus Anwendersicht formuliert. Diese Anforderungen sind von technisch
formulierten Anforderungen zu unterscheiden, wie etwa Skalierbarkeit, Offenheit oder Fehlertoleranz (siehe z. B. [Emmerich 2003], S. 20-26).
Ein einfaches Beispiel f¨
ur Integrationsanforderungen ist der Wunsch, bei parallel genutzten
Anwendungssystemen Benutzerkennung und Passwort, sofern erforderlich, nur einmal eingeben
zu m¨
ussen und nicht getrennt f¨
ur jedes der Anwendungssysteme. Eine weiteres Beispiel ist der
Wunsch nach automatischer Verf¨
ugbarkeit von Befunden aus einem zentralen Klinikumslabor
oder einer radiologischen Abteilung auf einem Stationsrechner. Ein drittes Beispiel ist der
Wunsch nach automatischer Verf¨
ugbarkeit von bei der Patientenaufnahme erfassten Patientenund Falldaten im Laborinformationssystem.
Kasten 2.1: Grundbegriffe (1): Informationen, Daten, Wissen
Die drei Bezeichnungen Information, Daten und Wissen haben ihren festen Platz in der Umgangssprache und es
gibt pers¨
onliche Vorstellungen davon, f¨
ur welche Begriffe sie stehen. In [Leiner et al. 1997], S. 22 werden sie wie folgt
definiert (siehe auch DIN 44300):
Information ist die Kenntnis u
¨ber bestimmte
”
Sachverhalte oder Vorg¨
ange.“
Daten sind Gebilde aus Zeichen oder kon”
tinuierliche Funktionen (z. B. Tonsignale), die
aufgrund bekannter oder unterstellter Abmachungen Informationen darstellen. Daten sind
die Grundlage oder das Ergebnis eines Verarbeitungsschrittes.“
Wissen ist die Kenntnis u
¨ber den in einem
”
Fachgebiet zu gegebener Zeit vorhandenen Konsens hinsichtlich Terminologie, regelhafter Zusammenh¨
ange und Handlungsrichtlinien. Wissen ist demnach auch Information im weiteren
Sinne.“
Abbildung: Daten, Informationen und Wissen in der Patientenversorgung (Quelle: [van Bemmel and Musen 1997],
Figure 1.1)
11
2 Integrationsanforderungen
Kasten 2.2: Grundbegriffe (2): Informationssystem, Anwendungssystem,
Integration
Ein Informationssystem sei nach [Haux et al. 1998], S. 18
das (. . . ) Teilsystem eines Unternehmens, das aus den informationsverarbeitenden Aktivit¨
aten und
”
den an ihnen beteiligten menschlichen und maschinellen Handlungstr¨
agern in ihrer informationsverarbeitenden Rolle besteht.“
Diese Definition ist eine Verallgemeinerung der in [Winter et al. 1998] erarbeiteten Definition f¨
ur Krankenhausinformationssysteme.
In der Regel k¨
onnen innerhalb eines Informationssystems Komponenten identifiziert werden, die die Erf¨
ullung ausgew¨
ahlter Aufgaben unterst¨
utzen und in diesem Zusammenhang technisch oder organisatorisch eine Einheit bilden.
Sie werden hier nach [Haux et al. 1998], S. 18 als Anwendungssysteme bzw. nach [Winter et al. 2001] als Anwendungsbausteine bezeichnet. Typische Anwendungssysteme in diesem Sinne sind ein Patientenverwaltungssystem, ein
Radiologieinformationssystem oder ein Archivverwaltungssystem.
Mit der Verwendung der Bezeichnung Anwendungsbaustein“ anstelle von Anwendungssystem“ wird betont, dass
”
”
eine Komponente bestimmte Funktionen zu Verf¨
ugung stellt, aber ohne die Integration mit anderen Komponenten
nicht oder nur wenig sinnvoll verwendet werden kann.
Integration ist in [Drosdowski 1994], S. 643 erkl¨
art als
1. [Wieder]herstellung einer Einheit [aus Differenziertem]; Vervollst¨
andigung. 2. Einbeziehung, Ein”
gliederung in ein gr¨
oßeres Ganzes; (. . . ) 3. Zustand, in dem sich etwas befindet, nachdem es integriert
worden ist; (. . . ) 4. Berechnung eines Integrals; (. . . )“
In dieser Arbeit wird Integration im Sinne der dritten Erkl¨
arung als Zustand, nicht als T¨
atigkeit oder Vorgang,
verstanden.
Es lassen sich viele weitere Beispiele f¨
ur Integrationsanforderungen nennen. Da eine vollst¨
andige Aufz¨
ahlung unm¨
oglich ist und nicht jede einzelne Anforderung diskutiert werden kann,
werden hier die folgenden Anforderungskategorien unterschieden, denen die meisten Anforderungen zugeordnet werden k¨
onnen:
–
–
–
–
–
–
–
physische Integration,
Datenintegration,
funktionale Integration,
semantische Integration,
Kontextintegration,
Pr¨
asentationsintegration und
Zugriffsintegration.
Die Aufteilung in die genannten Kategorien wurde haupts¨
achlich auf der Basis der Werke
[Haux et al. 2004], [van Bemmel and Musen 1997], [IMBI/MI 2001] (siehe Anhang A) und
[Olsen 1995] vorgenommen, unter zus¨
atzlicher Ber¨
ucksichtigung von [HIMSS/RSNA 2003a]
und [Heimbigner and McLeod 1985]. [HIMSS/RSNA 2003a] ist dabei der erste Teil des
IHE IT Infrastructure Technical Framework (IHE ITI TF) der Initiative Integrating the Healthcare Enterprise (IHE). Er spezifiziert Integrationsanforderungen f¨
ur die Integration radiologischer Anwendungssysteme mit anderen Anwendungssystemen1. F¨
ur die hier vorgenommene
Einteilung von Integrationsanforderungen ist dabei haupts¨
achlich die darin angegebene Eintei1
Der IHE IT Infrastructure Technical Framework, Vol. 1 ([HIMSS/RSNA 2003a]) darf nicht mit dem IHE
Technical Framework, Vol. 1 ([HIMSS/RSNA 2003b]) verwechselt werden. W¨
ahrend letzteres Werk haupts¨
achlich Integrationsanforderungen innerhalb radiologischer Organisationseinheiten spezifiziert, enth¨
alt der
hier zitierte IHE IT Infrastructure Technical Framework Spezifikationen f¨
ur die Integration radiologischer
Anwendungssysteme mit den Anwendungssystemen anderer Organisationseinheiten.
12
2.2 Kategorien von Integrationsanforderungen
Abbildung 2.1: IT-Infrastruktur-Integrationsprofile des IHE IT Infrastructure Technical Framework, Vol. 1 (Quelle:
[HIMSS/RSNA 2003a], Figure 2-1, S. 10)
lung von Nutzeranforderungen in Integrationsprofile relevant (Abbildung 2.1; [HIMSS/RSNA
2003a], S. 10-14).
Die in den Abschnitten zu den einzelnen Anforderungskategorien angegebenen zahlreichen
Zitate aus den genannten Werken sollen die Vielfalt der vorhandenen Einteilungen und Definitionen widerspiegeln. Die hier gew¨
ahlte Einteilung der Kategorien entstand durch Auswahl
und Zusammenfassung.
2.2 Kategorien von Integrationsanforderungen
Die folgenden Definitionen beschreiben Kategorien von Integrationsanforderungen. Beispiele
f¨
ur einzelne Anforderungen, die sich den Kategorien zuordnen lassen, sind
– die Forderung nach Einbindung von Tablet-PCs mit Funknetz in das Klinikumsnetzwerk,
um mobilen Datenzugriff zu erm¨
oglichen,
¨
– die Forderung nach automatischer Ubermittlung
von Patientenstammdaten und Falldaten von einem Patientenverwaltungssystem an andere Anwendungssysteme,
– die Forderung nach Einbindung eines Diagnosen- und Prozedurenverschl¨
usselungsmoduls
in unterschiedliche Anwendungssysteme,
– die Forderung nach Bereitstellung und automatischer Anwendung eines aktuellen Diagnosenkataloges auf der Basis der jeweils g¨
ultigen Version der Diagnosenklassifikation
ICD10 mit Beginn ihrer G¨
ultigkeit in allen betroffenen Anwendungssystemen,
– die Forderung nach automatischer Patientenauswahl auf dem Bildserver der Radiologie,
abh¨
angig vom ausgew¨
ahlten Patienten im Stationsmanagementsystem,
– die Forderung nach einheitlicher Pr¨
asentation von Befunden an Stations- und OP-Arbeitspl¨
atzen oder
– die Forderung nach gleichen Benutzerkennungen f¨
ur PC- bzw. Dom¨
anenanmeldungen,
das Stationsmanagementsystem sowie den radiologischen Bildserver.
Hinweis: Im Text der Arbeit wird mit Bezug auf Anforderungskategorien oft die Forderung
”
nach . . .“ oder Anforderung . . .“ geschrieben, um lange Formulierungen wie Anforderungen
”
”
13
2 Integrationsanforderungen
aus der Kategorie . . .“ zu vermeiden.
2.2.1 Physische Integration
Definition 2.1 : Physische Integration ist gegeben, wenn die f¨
ur jeglichen Datenaustausch
notwendige physische Infrastruktur vorhanden ist.
Ende — Definition
Die angegebene Definition wird gest¨
utzt durch die Definition in [Olsen 1995]:
Technical integration means that you can use various application programs (in multi-session mode) from
”
a terminal or workstation anywhere in the hospital, no matter where the relevant application program
resides. It also means that the technical infrastructure (network, etc.) for communicating data from one
computer to another, inside or outside the hospital, is available. (. . . )“ ([Olsen 1995])
Zur physischen Integration existieren heute verbreitete Standards wie z. B. die IEEE-Standards
802.X f¨
ur Rechnernetzwerke.
Zur Anforderungskategorie der physischen Integration geh¨
ort, zumindest im weiteren Sinne,
das Integrationsprofil Consistent Time“ im IHE ITI TF. Die Synchronisation der Systemzeit
”
verschiedener Rechner oder anderer physischer Komponenten ist wichtige Voraussetzung f¨
ur
das Zusammenarbeiten von Betriebssystemen und Anwendungssystemen:
Consistent Time Profile defines mechanisms to synchronize the time base between multiple actors and
”
computers. Various infrastructure, security, and acquisition profiles require use of a consistent time base
on multiple computers. (. . . )“ ([HIMSS/RSNA 2003a], S. 13)
Hinweis: Auch die Realisierung verschiedener Anwendungssysteme auf ein und demselben
Rechner ist physische Integration.
2.2.2 Datenintegration
Definition 2.2 : Datenintegration ist gegeben, wenn bestimmte Daten, z. B. Krankenhausfalldaten, nur einmal erfasst werden m¨
ussen, auch wenn die dadurch repr¨
asentierten Informationen bei der Arbeit mit mehreren Anwendungssystemen ben¨
otigt werden.
Ende — Definition
Die angegebene Definition wird gest¨
utzt durch die Definitionen in [Haux et al. 2004], [van
Bemmel and Musen 1997] und [Heimbigner and McLeod 1985]:
Data integration is guaranteed in a hospital information system when data which have been recorded are
”
available wherever they are needed, without having to be reentered. (. . . )“ ([Haux et al. 2004], S. 127)
Data integration. This means that data registered in one application are available to another application,
”
if necessary and provided that it is not conflicting with confidentiality. This prevents repeated recording of
the same data and reduces the risk of mistakes.“ ([van Bemmel and Musen 1997], S. 351)
—Data communication. Each component has a collection of data, and other components may be interested
”
in accessing some portion of those data. Exchanging the data is the primary activity in a federation, and
so a mechanism to support data sharing is essential to the operation of a federation.“ ([Heimbigner and
McLeod 1985], S. 255)
Die Definition in [Olsen 1995] best¨
atigt zun¨
achst die vorhergehenden Definitionen und fordert
zus¨
atzlich f¨
ur den Zustand der vollst¨
andigen Datenintegration die einmalige Speicherung jedes
Datums:
14
2.2 Kategorien von Integrationsanforderungen
Data integration means that a particular data item — once recorded — is immediately available for all
”
relevant and authorized purposes performed by any relevant application. Programs can access data from
other applications allowing data to be validated against each other at the time of recording in order to
ensure a high data quality. Full data integration requires that each data item is stored in only one logical
place, which is ‘known’ by all relevant applications. All data will, however, not necessarily have to be placed
in the same physical database nor on the same data server. (. . . )“ ([Olsen 1995])
Die einmalige Speicherung wird durch die Definition dieser Arbeit nicht gefordert.
Diese Anforderungskategorie korrespondiert mit dem Integrationsprofil Retrieve Informati”
on for Display“ im IHE ITI TF:
Retrieve Information for Display enables simple and rapid access to patient information for better care.
”
It supports access to existing persistent documents in well-known presentation formats such as CDA, PDF,
JPEG, etc. It also supports access to specific key patient-centric information such as allergies, current
medications, summary of reports, etc. for presentation to a clinician. (. . . )“ ([HIMSS/RSNA 2003a], S. 12)
2.2.3 Funktionale Integration
Definition 2.3 : Funktionale Integration ist gegeben, wenn Funktionen, die in mehreren
Anwendungssystemen ben¨
otigt werden, m¨
oglichst nur einmal implementiert sind und aus den
Anwendungssystemen aufgerufen werden k¨
onnen; dazu geh¨
oren u. a. das Pr¨
asentieren von
Befunddokumenten am Bildschirm und das Verschl¨
usseln von Diagnosen und Prozeduren.
Ende — Definition
Die angegebene Definition wird gest¨
utzt durch die Definitionen in [van Bemmel and Musen
1997], [Heimbigner and McLeod 1985] und [Olsen 1995]:
Functional integration means that functions of different applications are available to the qualified user
”
within one user environment.“ ([van Bemmel and Musen 1997], S. 351)
—Transaction sharing. A component may not wish to share its data directly, but rather to share operati”
ons upon its data. This may be the case if the data are sensitive or have consistency constraints attached
to them. In any case, components must be able to define transactions that can be invoked by other components.“ ([Heimbigner and McLeod 1985], S. 255)
Functional integration means that the user can use a function from one application program in connection
”
with other applications in a seamless way.“ ([Olsen 1995])
Relevanz der funktionalen Integration f¨
ur Anwendungssystemnutzer
F¨
ur die Nutzer von Anwendungssystemen kann es zun¨
achst ohne Bedeutung sein, ob eine
bestimmte Funktionalit¨
at, z. B. das Suchen von Patientendaten, nur einmal in einem Anwendungssystem implementiert ist und dann von mehreren anderen Anwendungssystemen genutzt
werden kann, oder ob die betreffende Funktionalit¨
at mehrfach implementiert ist. In letzterem
Fall muss nur“ Datenintegration zwischen den betreffenden Anwendungssystemen gegeben
”
sein (vgl. auch die Definition von Funktionsintegration in [Lehmann and Meyer zu Bexten
2002], S. 517).
Im Fall der Mehrfachimplementierung einer bestimmten Funktionalit¨
at in mehreren Anwendungsbausteinen ist u. U. neben der erforderlichen Datenintegration auch Pr¨
asentationsintegration (siehe Abschnitt 2.2.6) oder ggf. auch Kontextintegration (siehe Abschnitt 2.2.5) zu
realisieren. Das gilt, wenn die betreffende Funktionalit¨
at die Interaktion mit den Anwendungssystemnutzern einschließt. Der mit der Realisierung der Integration verbundene Aufwand kann
bei funktionaler Integration u. U. geringer sein.
15
2 Integrationsanforderungen
Dualit¨
at von Datenintegration und funktionaler Integration
Zwischen Datenintegration und funktionaler Integration besteht eine Dualit¨
atsbeziehung bez¨
uglich des Zugriffs auf Informationen:
1. Wenn zwischen verschiedenen Anwendungssystemen funktionale Integration hinsichtlich
einer bestimmten Funktionalit¨
at gegeben ist, dann m¨
ussen die mit dieser Funktionalit¨
at
verarbeiteten Informationen, genauer: die die Informationen repr¨
asentierenden Daten,
nicht zwischen den betreffenden Anwendungssystemen abgeglichen werden. Der Zugriff
erfolgt nur u
¨ ber die gemeinsam genutzten Funktionen, wodurch eine einmalige Speicherung gen¨
ugt.
2. Wenn die in verschiedenen Anwendungssystemen ben¨
otigte Funktionalit¨
at mehrfach implementiert ist, dann kann durch Datenintegration prinzipiell dieselbe Leistungsf¨ahigkeit
der Anwendungssysteme wie bei funktionaler Integration erreicht werden.
Im zweiten Fall ist, wie bereits im Zusammenhang mit der Relevanz der funktionalen Integration beschrieben, mit erh¨
ohtem Integrationsaufwand f¨
ur zus¨
atzliche Pr¨
asentationsintegation und
Kontextintegration zu rechnen.
2.2.4 Semantische Integration
Definition 2.4 : Semantische Integration ist gegeben, wenn in unterschiedlichen Anwendungssystemen dieselben Begriffssysteme verwendet werden, d. h. wenn Daten gleich interpretiert werden.
Ende — Definition
Die Verwendung von Begriffssystemen wird im Kasten Exkurs zur semantischen Integration“
”
er¨
ortert. Zur semantischen Integration geh¨
ort u. a. der Abgleich von Diagnose- und Prozedurkatalogen zwischen verschiedenen Anwendungssystemen.
Die angegebene Definition wird gest¨
utzt durch die Definition in [Olsen 1995]:
Semantic integration means that the sender and the receiver in a communication of data use the same
”
terminology, data definitions and reference model, in order to ensure full and correct understanding of the
semantic content.“ ([Olsen 1995])
Zu dieser Anforderungskategorie geh¨
ort auch das Integrationsprofil Patient Identifier Cross”
referencing“ im IHE ITI TF:
The PIX profile supports the cross-referencing of patient identifiers from multiple Patient Identifier Do”
mains. These cross-referenced patient identifiers can then be used by “identity consumer” systems to correlate information about a single patient from sources that “know” the patient by different identifiers. (. . . )“
([HIMSS/RSNA 2003a], S. 12)
Wenn es nicht m¨
oglich ist, dieselben Begriffssysteme zu verwenden, dann muss durch geeig¨
nete Funktionalit¨
at eine gegenseitige Ubersetzung
der Begriffssysteme erm¨
oglicht werden.
2.2.5 Kontextintegration
Definition 2.5 : Kontextintegration ist gegeben, wenn beim parallelen Arbeiten mit mehreren Anwendungssystemen ein bestimmter Kontext, z. B. Anmeldekontext oder Patientenkontext, nur einmal hergestellt werden muss und dann automatisch zwischen den Anwendungssystemen abgeglichen wird.
16
2.2 Kategorien von Integrationsanforderungen
Kasten 2.3: Exkurs zur semantischen Integration
Semantische Integration von Anwendungssystemen soll sicherstellen, dass die Bedeutung von bestimmten Daten,
d. h. ihre Interpretation, in diesen Anwendungssystemen dieselbe ist. Die Daten sollen also dieselben Informationen
repr¨
asentieren.
Legt man Definitionen aus der Logik zugrunde, dann ist eine Interpretation eine Abbildung von Symbolen auf
Objekte der realen Welt. Zu den Objekten z¨
ahlen dabei nicht nur Gegenst¨
ande, sondern auch Aktionen, Informationen
oder Funktionen. Bei der Implementierung von Anwendungssystemen (Software Engineering, Customizing) werden
spezielle Modelle der realen Welt erstellt, um die Daten, welche Informationen u
asentieren, in
¨ber die reale Welt repr¨
geeigneten Strukturen speichern und verarbeiten zu k¨
onnen.
F¨
ur viele Informationen z. B. f¨
ur Laborergebnisse, Diagnosen oder Angaben zur Aufnahmeart, wird die beabsichtigte Interpretation der Daten dadurch sichergestellt, dass zu den zu interpretierenden Arbeits“-Daten zus¨
atzliche
”
Daten, die erkl¨
arende Informationen repr¨
asentieren, in den Anwendungssystemen gespeichert werden. Beispiele sind
Referenzbereichskataloge inkl. zugeh¨
origer Bewertungen f¨
ur Laborergebnisse oder Diagnosenkataloge mit Diagnosenk¨
urzeln und zugeh¨
origen erkl¨
arenden Langtexten. Diese zus¨
atzlichen Daten stellen als Texte und/oder Bilder Bez¨
uge
zu Objekten der realen Welt her.
Eine Sammlung von erkl¨
arenden Daten f¨
ur bestimmte Informationen wird hier Begriffssystem genannta (nach
[Leiner et al. 1997], S. 38 und 125). In Begriffssystemen kann sich, wie z. B. im ICD10-Diagnosenkatalog, neben
der Bereitstellung von Erkl¨
arungstexten eine Systematik der enthaltenen Symbole und folglich eine Systematik der
Objekte der realen Welt ausdr¨
ucken.
Mit den bisherigen Erkl¨
arungen heißt semantische Integration von bestimmten Anwendungssystemen, dass in
diesen Anwendungssystemen dieselben Begriffssysteme zur Interpretation von Daten zur Verf¨
ugung stehen oder dass,
bei Verwendung von verschiedenen Begriffssystemen, die betreffenden Begriffssysteme durch spezielle Funktionalit¨
at
aufeinander abgebildet werden.
Abgrenzung zur semantischen Datenmodellierung und zur semantischen Integrit¨
at
In der Informatik ist der Begriff semantische Datenmodellierung bekannt. Die semantische Datenmodellierung ist
eine Methode zur Modellierung von Informationen, die sehr oft zur Erstellung von konzeptionellen Datenmodellen
verwendet wird. Konzeptionelle Datenmodelle formalisieren die reale Welt zun¨
achst unabh¨
angig von Implementierungstechniken, i. d. R. mit Hilfe von Klassen und ihren Beziehungen. Aus konzeptionellen Datenmodellen werden,
abh¨
angig von Implementierungstechniken, logische Datenmodelle gebildet, z. B. relationale oder objektorientierte
¨
Datenmodelle. Beim Ubergang
von einem konzeptionellen Datenmodell zu einem relationalen Datenmodell m¨
ussen
beispielsweise n:m-Beziehungen aufgel¨
ost oder Spezialisierungsbeziehungen durch geeignete Relationen ersetzt werden
([Vossen 2000], S. 72-79 (Abschnitt 4.3), [Balzert 1996], S. 137-162 (Kapitel 2)).
Bestimmte Beziehungen im logischen Datenmodell, die f¨
ur eine ad¨
aquate Abbildung der realen Welt notwendig
sind, z. B. Fremdschl¨
usselbeziehungen, nennt man auch semantische Integrit¨
atsbedingungen. Oft wird beispielsweise
festgelegt, dass Objekte nur u
urfen, z. B. durch
¨ber Elemente aus einem Begriffsverzeichnis beschrieben werden d¨
eine Vorschrift zur Dokumentierung von Diagnosen nach ICD10. Daf¨
ur werden im logischen Datenmodell semantische
Integrit¨
atsbedingungen, typischerweise Fremdschl¨
usselbeziehungen, angegeben.
a
Auch wenn in den erkl¨
arenden Daten nur ein einziger Begriff beschrieben wird, k¨
onnen diese Daten als Repr¨
asentation eines Begriffssystems betrachtet werden.
Ende — Definition
Abbildung 2.2 zeigt ein Beispiel f¨
ur drei hinsichtlich des Anmeldekontextes und des Patientenkontextes abzugleichende Anwendungssysteme.
Die angegebene Definition wird gest¨
utzt durch die Definition in [Haux et al. 2004]:
Contextual integration means that the context is preserved when the application component is changed,
”
e.g., at a healthcare professional workstation. (. . . )“ ([Haux et al. 2004], S. 128)
Diese Anforderungskategorie korrespondiert mit dem Integrationsprofil Patient Synchroni”
zed Applications“ im IHE ITI TF:
Patient Synchronized Applications supports viewing data for a single patient among otherwise indepen”
dent and unlinked applications on a user’s workstation. Its implementation reduces the repetitive tasks of
17
2 Integrationsanforderungen
selecting the same patient in multiple applications. It also improves patient safety by reducing the chance
of medical errors caused by viewing the wrong patient’s data. (. . . )“ ([HIMSS/RSNA 2003a], S. 12)
Sie u
¨ berdeckt teilweise das Integrationsprofil Enterprise User Authentication“ im IHE ITI TF
”
(vgl. Abschnitt 2.2.7).
2.2.6 Pr¨
asentationsintegration
Definition 2.6 : Pr¨
asentationsintegration ist gegeben, wenn Eingabe- und Pr¨
asentationselemente f¨
ur die gleichen Daten in unterschiedlichen Anwendungssystemen gleich oder ¨ahnlich
gestaltet sind und deshalb nicht jeweils neu erlernt werden m¨
ussen.
Ende — Definition
Die angegebene Definition wird gest¨
utzt durch die Definitionen in [Haux et al. 2004], [van
Bemmel and Musen 1997] und [Olsen 1995]:
Presentation integration is guaranteed when different application components represent data as well as
”
user interfaces in a unified way. (. . . )“ ([Haux et al. 2004], S. 128)
Abbildung 2.2: Drei parallel genutzte Anwendungssysteme: ein Stationsmanagementsystem, ein OP-Dokumentationssystem und der Intranet-Server des Zentrallabors (Quelle: Bildschirmfoto von einem PC am UKL)
18
2.2 Kategorien von Integrationsanforderungen
Presentation integration implies that data from various applications are presented to the user in an
”
adequate and consistent way. Especially for dynamically changing data, this is not self-evident.“ ([van
Bemmel and Musen 1997], S. 351)
User interface integration means that features like screen dialogue, function keys, help functions, macros,
”
presentation layout etc., are roughly the same in all applications.“ ([Olsen 1995])
2.2.7 Zugriffsintegration
Definition 2.7 : Zugriffsintegration ist gegeben, wenn die Verwaltung von Benutzerkennungen und Zugriffsrechten f¨
ur unterschiedliche Anwendungssysteme einheitlich erfolgt.
Ende — Definition
Die Definition aus [Haux et al. 2004] schließt die Bereitstellung von Anwendungssystemen ein
und ist allgemeiner als die Definition dieser Arbeit:
Access integration is guaranteed when the application components needed for the completion of a certain
”
task can be used where they are needed. (. . . )“ ([Haux et al. 2004], S. 128)
Diese Anforderungskategorie korrespondiert mit dem Integrationsprofil Enterprise User Au”
thentication“ im IHE ITI TF:
Enterprise User Authentication (EUA) – Defines a means to establish one name per user that can then
”
be used on all of the devices and software that participate in this integration profile. It greatly facilitates
centralized user authentication management and provides users with the convenience and speed of a single
sign-on. This profile leverages Kerberos (RFC 1510) and the HL7 CCOW standard (user subject). (. . . )“
([HIMSS/RSNA 2003a], S. 12)
19
3 Informationssystemarchitekturen — Eine Einf¨
uhrung
3.1 Vorbemerkungen
Ar|chi|tek|tur die; -, -en (aus gleichbed. lat. architectura): 1. a) (ohne Plur.) Baukunst [als wissen”
schaftliche Disziplin]; b) Baustil. 2. der nach den Regeln der Baukunst gestaltete Aufbau eines Geb¨
audes.“
([Drosdowski 1994], S. 134)
Mit dieser Erkl¨arung aus einem Fremdw¨
orterbuch k¨
onnte der Baukunst die Informatik als
Kunst des Aufbaus von Informationssystemen gegen¨
ubergestellt werden. Der ”nach den Regeln
der Baukunst gestaltete Aufbau eines Geb¨
audes“ entspr¨
ache dann dem nach den Regeln der Informatik
gestalteten Aufbau eines Informationssystems.
DIE Definition f¨
ur Architektur existiert nicht. In den meisten Definitionen spiegelt sich die
Idee der Zerlegung eines Systems in Komponenten mit bestimmten Beziehungen wider (siehe
Kasten Grundbegriffe (3)“, vgl. [Bachmann et al. 2000], S. 1-2).
”
Jede Definition f¨
ur Architektur, die aus einem Satz oder nur wenigen S¨
atzen besteht, kann
die Komplexit¨
at des Architekturbegriffes, auch f¨
ur Informationssysteme, kaum fassen. Die Betrachtung der Architektur von Informationssystemen kann bez¨
uglich sehr unterschiedlicher
Fragestellungen und unter Ber¨
ucksichtigung sehr unterschiedlicher Details erfolgen.
Eine Unterst¨
utzung bei der Orientierung innerhalb dieser Vielfalt geben Rahmenwerke zu
Informationssystemarchitekturen. Sie beschreiben Vorgehens-Referenzmodelle f¨
ur die Architekturentwicklung, verschiedene Sichten auf die Architektur oder auch Architektur-Referenzmodelle. Rahmenwerke unterst¨
utzen das Management von Informationssystemen, d. h. die
Initiierung und Steuerung von Projekten, das Ausw¨
ahlen von Analyse- und Entwurfsmethoden, das Treffen von Auswahlentscheidungen f¨
ur oder gegen bestimmte zur Auswahl stehende
Komponenten usw. Im Kapitel 4 werden einige Rahmenwerke vorgestellt.
Kasten 3.1: Grundbegriffe (3): Definitionen f¨
ur Architektur
Standard IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems“:
”
Architecture: the fundamental organization of a system embodied in its components, their relati”
onships to each other and to the environment and the principles guiding its design and evolution.“
([Hilliard 2000])
The Open Group Architectural Framework:
In TOGAF, “Architecture” has two meanings depending upon its contextual usage:
”
1. A formal description of a system, or a detailed plan of the system at component level to guide
its implementation.
2. The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time.“ ([The Open Group 2001], Part I, TOGAF FAQ)
Spezifikation der Unified Modeling Language (UML):
Architecture: The organizational structure and associated behavior of a system. An architec”
ture can be recursively decomposed into parts that interact through interfaces, relationships that
connect parts, and constraints for assembling parts. Parts that interact through interfaces include
classes, components and subsystems.“ ([OMG 2003c], Glossary-2)
21
3 Informationssystemarchitekturen — Eine Einf¨
uhrung
3.2 Architektur: Komponenten und ihre Beziehungen
Das Reference Model for Open Distributed Processing (RM-ODP) der International Organization for Standardization (ISO) wurde auf der Grundlage ausf¨
uhrlicher Definitionen der bei
der Architekturbeschreibung zul¨assigen Begriffe entwickelt. Der Standard ISO/IEC 10746-2
(RM-ODP Foundations) definiert beispielsweise die im Standard ISO/IEC 10746-3 (RM-ODP
ur die ArchiArchitecture) verwendeten Begriffe zur Architekturbeschreibung1. Darin werden f¨
tekturbeschreibung u. a.
– die Begriffskategorie basic modelling concepts mit Begriffen wie Objekt (object), Aktion
(action), Schnittstelle (interface), Verhalten (behaviour) usw.,
– die Begriffskategorie specification concepts mit Begriffen wie Komposition (composition),
Verfeinerung (refinement), Typ (type), Subtyp (subtype) usw. und
– die Begriffskategorie structuring concepts mit
· Begriffen zur Organisation von Objekten, z. B. Gruppe (group), Konfiguration (configuration) und Dom¨
ane (domain),
· Begriffen zur Beschaffenheit von Systemen und Objekten, z. B. Transparenz (transparency) und Vertrag (contract),
· Begriffen zur Bezeichnung, z. B. Namensraum (name space) und Namensgraph (naming graph),
· Begriffen zur Verhaltensweise von Objekten, z. B. initiierendes Objekt (initiating
object) und Versagen (failure), und
· Begriffen zum Management von Systemen, z. B. Anwendungsmanagement (application management) und Managementinformation (management information)
unterschieden (Kasten Ausz¨
uge aus ISO/IEC 10746-2 (RM-ODP Foundations)“). Die u
¨ brigen
”
Kategorien definieren Grundlagenbegriffe wie Entit¨
at (entity), Aussage (proposition) oder Satz
(sentence) und Begriffe zur Konformit¨
atsbeschreibung wie Portabilit¨
at (portability) ([ISO/IEC
JTC 1 1996b], S. 2-18, siehe auch Abschnitt 4.2.2).
Die Begriffskategorien aus dem Standard ISO/IEC 10746-2 (RM-ODP Foundations) implizieren, dass die Architektur eines Informationssystems durch die Spezifikation von Komponenten (im Standard: Objects“) und die Spezifikation von Beziehungen zwischen diesen Kom”
ponenten festgelegt ist. Zur Spezifikation von Komponenten werden neben den Basis-Modellierungsbegriffen (basic modelling concepts) die Spezifikationsbegriffe (specification concepts)
verwendet. F¨
ur die Spezifikation von Beziehungen werden neben den Basis-Modellierungsbegriffen die Strukturbegriffe (structuring concepts) verwendet. Die verschiedenen Unterkategorien
der Strukturbegriffe lassen erkennen, dass Architekturbeschreibungen durch die Nutzung vieler
unterschiedlicher Begriffe sehr vielf¨
altig sein k¨
onnen.
Definitionen f¨
ur den Architekturbegriff und f¨
ur Architekturbeschreibungen, die ein pr¨
azises
Verst¨
andnis und infolgedessen einen Vergleich verschiedener Architekturkonzepte und Architekturstile erm¨
oglichen, wurden auch ausf¨
uhrlich in den Arbeiten der School of Computer
Science der Carnegie Mellon University (Pittsburgh, USA) entwickelt (siehe u. a. [Garlan
and Shaw 1994], [Abowd et al. 1995], [Shaw and Garlan 1995], [Garlan et al. 1997] und
1
Ein weiteres Beispiel f¨
ur Begriffsdefinitionen, die einer bestimmten Architekturbeschreibung zugrundegelegt
werden, ist der Abschnitt 5 im Standard ISO/IEC 7498-1. Er definiert wichtige Begriffe f¨
ur die Architekturbeschreibung in den Abschnitten 6 und 7 desselben Standards, in denen das bekannte OSI-Referenzmodell
definiert wird ([ISO/IEC JTC 1 1996c], siehe auch Abschnitt 4.2.1).
22
3.2 Architektur: Komponenten und ihre Beziehungen
Kasten 3.2: Ausz¨
uge aus ISO/IEC 10746-2 (RM-ODP Foundations)
8 Basic modelling concepts
”
The detailed interpretation of the concepts defined in this clause will depend on the specification language
concerned, but these general statements of concepts are made in a language-independent way to allow the
statements in different languages to be interrelated.
The basic concepts are concerned with existence and activity: the expression of what exists, where it is and
what it does.
8.1 Object: A model of an entity. An object is characterized by its behaviour (. . . ) and, dually, by its state
(. . . ). An object is distinct from any other object. An object is encapsulated, i.e. any change in its state can
only occur as a result of an internal action or as a result of an interaction (. . . ) with its environment (. . . ).
(. . . )
9 Specification concepts
9.1 Composition
a) (Of objects) – A combination of two or more objects yielding a new object, at a different level of abstraction.
The characteristics of the new object are determined by the objects being combined and by the way they
are combined. The behaviour of a composite object is the corresponding composition of the behaviour of the
component objects.
b) (Of behaviours) – A combination of two or more behaviours yielding a new behaviour. The characteristics of
the resulting behaviour are determined by the behaviours being combined and the way they are combined.
(. . . )“
(zitiert aus [ISO/IEC JTC 1 1996b], S. 3-5)
[Shaw and Garlan 1996]). Diese und viele andere Arbeiten zur Architektur sind haupts¨
achlich
auf Softwarearchitekturen bezogen. Sie k¨
onnen jedoch auch allgemeiner auf Informationssystemarchitekturen angewendet werden, wenn softwarespezifische Details weggelassen werden.
Sie bilden eine wesentliche Grundlage f¨
ur die folgenden Ausf¨
uhrungen.
Viele Werke geben eine kurze Definition f¨
ur Architektur an (vgl. Kasten Gundbegriffe (3)“),
”
die dann durch erg¨
anzende Definitionen und ausf¨
uhrliche Erkl¨
arungen zu einer umfangreichen
Beschreibungssprache bzw. Modellierungsmethode ausgebaut werden. Der folgende Satz aus
[Shaw and Garlan 1996]2 sei hier Ausgangspunkt f¨
ur die Definition des Architekturbegriffes3 :
The architecture of a software system defines that system in terms of computational components and
”
interactions among those components.“ ([Shaw and Garlan 1996], S. 3)
Der Satz a
ur Architektur. In
¨hnelt den in Kasten Grundbegriffe (3)“ angegebenen Definitionen f¨
”
allen Beschreibungen und Definitionen werden neben den Komponenten eines Systems auch die
Beziehungen zwischen diesen Komponenten als wesentliche Elemente der Architektur genannt
(vgl. Kasten Grundbegriffe (3)“):
”
(. . . ) components and interactions among those components.“ (aus oben zitiertem Satz)
”
(. . . ) components, their relationships to each other (. . . ).“ ([Hilliard 2000])
”
(. . . ) structure of components, their interrelationships, (. . . )“ ([The Open Group 2001], Part I, TOGAF
”
FAQ)
(. . . ) organizational structure and associated behavior of a system. An architecture can be recursively
”
decomposed into parts that interact through interfaces, relationships that connect parts, and constraints
for assembling parts. (. . . )“ ([OMG 2003c], Glossary-2)
2
3
Originalbeitrag ist [Garlan and Shaw 1994]
Diese Definition wird auch im Model Driven Architecture Guide der Object Management Group referenziert
([OMG 2003b], vgl. Abschnitt 4.2.3).
23
3 Informationssystemarchitekturen — Eine Einf¨
uhrung
(. . . ) we find components, both primitive and composite; rules of composition that allow the construction
”
of nonprimitive components, or systems; and rules of behaviour that provide semantics for the system.“
([Shaw and Garlan 1996], S. 4)
Auf der Basis der bisherigen Ausf¨
uhrungen wird Architektur von Informationssystemen hier
folgendermaßen definiert:
Definition 3.1 Die Architektur eines Informationssystems ist die Beschreibung seiner Komponenten und der Beziehungen zwischen den Komponenten.
Ende — Definition
Universell anwendbare Definitionen bzw. Vorgehensweisen zur Ermittlung von Komponenten
und Beziehungen innerhalb einer Architektur existieren bisher nicht. Die Kriterien f¨
ur die
Abgrenzung von Komponenten und f¨
ur die Beschreibung ihrer Beziehungen h¨
angen von
– der Art des Systems, dessen Architektur betrachtet wird,
– den Zielen der Architekturbetrachtung und
– den eingenommenen Sichtweisen
ab. Bei der Betrachtung der Architektur eines Informationssystems k¨
onnen beispielsweise Informationsklassen der verarbeiteten Informationen die Rolle der Komponenten einnehmen. Die
Beziehungen zwischen den Informationsklassen nehmen dann die Rolle der Beziehungen zwischen den Komponenten ein. Die Rolle der Komponenten kann aber z. B. auch durch Klassen
in einem objektorientierten Softwareentwurf eingenommen werden; die Verkn¨
upfungen von
Objekten, die durch die Festlegung von gegenseitigen Methodenaufrufen entstehen, z. B. in
Sequenzdiagrammen, nehmen dann die Rolle von Interaktionsbeziehungen zwischen den Komponenten ein (siehe z. B. [Emmerich 2003], S. 48-50).
Architekturentwicklungs- bzw. Architekturweiterentwicklungsprojekte verlangen also nach
einer Festlegung von Sichtweisen auf die Architektur und von Zielen der Architekturbetrachtung, abh¨
angig von der Art des betrachteten Systems. Darauf aufbauend k¨
onnen dann die
m¨
oglichen bzw. sinnvollen Komponententypen und Beziehungstypen festgelegt werden. Ein
solches Vorgehen ist, wenn keine Enpfehlungen oder Vorgaben genutzt werden, f¨
ur die meisten
Projekte zu aufwendig. Deshalb wurden von verschiedenen Organisationen aber auch Einzelautoren Rahmenwerke f¨
ur Informationssystemarchitekturen entwickelt. Sie sind Orientierungshilfen in der theoretischen Vielfalt von Sichtweisen, Komponententypen usw. In Kapitel 4 werden
einzelne Rahmenwerke f¨
ur Informationssystemarchitekturen vorgestellt.
3.3 Architekturstile
Wenn Beschreibungen von Komponenten und ihren Beziehungen, d. h. Architekturen, nicht nur
f¨
ur ein einzelnes, sondern f¨
ur mehrere Systeme gelten, dann werden die betreffenden Architekturen auch als Architekturstile bezeichnet. Anstelle von Stil“ wird oft auch die Bezeichnung
”
Muster (pattern) oder Entwurfsmuster verwendet ([Shaw and Garlan 1996], S. 19, [Gamma
et al. 1997], S. 2-4).
In [Gamma et al. 1997] wird, mit Bezug zur objektorientierten Entwicklung, der Begriff
Entwurfsmuster folgendermaßen definiert:
Entwurfsmuster (. . . ) sind Beschreibungen zusammenarbeitender Objekte und Klassen, die maßgeschnei”
dert sind, um ein allgemeines Entwurfsproblem in einem bestimmten Kontext zu l¨
osen.“ ([Gamma et al.
1997], S. 4)
24
3.3 Architekturstile
a)
b)
c)
Abbildung 3.1: Ein Komponententyp (a), ein Konnektorentyp (b) und eine Konfiguration (c) (Quelle [Abowd et al.
1995], S. 329-331, Abb. 3 - Abb. 5)
In der Literatur zu softwarebezogenen Architekturstilen wird einleitend oft auch die vom ech”
ten“ Architekten Christopher Alexander in seinem Werk A pattern language : towns, buildings,
”
construction“ ([Alexander 1977]) angegebene Beschreibung des Begriffes Muster zitiert:
Jedes Muster beschreibt ein in unserer Umwelt best¨
andig wiederkehrendes Problem und erl¨
autert den Kern
”
der L¨
osung f¨
ur dieses Problem, so dass sie diese L¨
osung beliebig oft anwenden k¨
onnen, ohne sie jemals ein
zweites Mal gleich auszuf¨
uhren.“ (¨
ubersetzt aus [Alexander 1977])
In [Shaw and Garlan 1996] (siehe auch [Garlan 1995]) werden Architekturstile u
¨ ber die
durch sie angegebenen
– Definitionen von Sprachen zur Beschreibung von Komponenten und ihren Beziehungen4
und
– Regeln f¨
ur die Nutzung der Sprachen
charakterisiert:
An architectural style (. . . ) defines a family of such systems in terms of a pattern of structural organization.
”
More specifically, an architectural style defines a vocabulary of components and connector types, and a set
of constraints on how they can be combined.“ ([Shaw and Garlan 1996], S. 20)
In [Abowd et al. 1995] (siehe auch [Shaw and Garlan 1996], S. 129-146) wird das, was unter
einem Architekturstil zu verstehen ist bzw. was zur Beschreibung eines Architekturstils geh¨
ort,
folgendermaßen pr¨
azisiert (Abbildung 3.1):
1. Zur Beschreibung von Architekturen wird eine formale abstrakte Syntax ben¨
otigt. Sie ist
unabh¨
angig von konkreten Architekturstilen. Die grundlegenden syntaktischen Elemente
sind5
4
5
In [Shaw and Garlan 1996] wie auch im nachfolgend referenzierten [Abowd et al. 1995] sind die Beziehungen
auf Interaktionsbeziehungen beschr¨
ankt. Andere Beziehungstypen, z. B. Aggregation oder Vererbung, werden
nicht ber¨
ucksichtigt.
In [Abowd et al. 1995] werden nicht die Bezeichnungen Komponententyp (component type) und Konnektorentyp (connector type) verwendet, sondern Komponente (component) und Konnektor (connector). In der
Definition der Konfigurationen wird jedoch deutlich, dass Typen gemeint sind, die dann in Konfigurationen
ausgepr¨
agt werden.
25
3 Informationssystemarchitekturen — Eine Einf¨
uhrung
Kasten 3.3: Grundbegriffe (4)
Definitionen f¨
ur Modell
Definition aus [Sch¨
utte 1998] Grunds¨
atze ordnungsm¨
aßiger Referenzmodellierung“:
”
Ein Modell ist das Ergebnis einer Konstruktion eines Modellierers, der f¨
ur Modellnutzer Elemente
”
eines Originals zu einer Zeit als relevant mit Hilfe einer Sprache deklariert.“ ([Sch¨
utte 1998], S. 59)
Definition aus [Haux et al. 2004] Strategic Information Management in Hospitals“:
”
A simplified depiction of reality or excerpts of it. Models are usually adapted to answer certain
”
questions or to solve certain tasks.“ ([Haux et al. 2004], S. 239)
Einfache Modelle von Informationssystemen k¨
onnen z. B. aus Listen von Anwendungsbausteinen, aus Tabellen von
Aufgaben der Informationsverarbeitung oder aus Grafiken von Rechnern und ihren Netzwerkverbindungen bestehen.
Erkl¨
arung und Definition f¨
ur Metamodell
Um Modellierung zu leiten und vergleichbar zu machen, aber auch um auf der Basis von existierenden Modellen u
¨bergreifende
Tatsachen zu formulieren, werden Metamodelle geschaffen. Das in dieser Arbeit erweiterte 3LGM2 ist ein Metamodell f¨
ur Informationssysteme.
Im Kasten Grundbegriffe (1)“ wurden die
”
Begriffe Information und Wissen definiert.
Mit ihnen kann f¨
ur die Beziehung zwischen
Modellen und Metamodellen von Informationssystemen folgende Erkl¨
arung angegeben werden: W¨
ahrend ein Modell Tatsachenkenntnisse u
¨ber ein Informationssystem darstellt, enth¨
alt ein Metamodell Wissen zur Interpretation von Modellen und gibt ggf. Vorschriften zur Erstellung von Modellen an.
Abbildung: Meta-Metamodell, Metamodell, Modell, Anwendungsdaten (Quelle: [OMG 2003c], Abschnitt 2.2.1)
Definition aus [Haux et al. 2004] Strategic Information Management in Hospitals“:
”
Language for describing models of a certain class. It usually describes the modeling framework,
”
which consists of the modeling syntax and semantics (. . . ), the representation of the objects (. . . ),
and (sometimes) the modeling rules (e.g., the modeling steps).“ ([Haux et al. 2004], S. 238)
Definitionen f¨
ur Referenzmodell
Definition aus [Winter et al. 1999] Referenzmodelle f¨
ur die Unterst¨
utzung des Managements von Krankenhausin”
formationssystemen“ (vgl. [Lehmann and Meyer zu Bexten 2002], S. 489):
Sei eine Klasse S von Sachverhalten gegeben. Ein Modell R ist Referenz f¨
ur eine Klasse S oder
”
R ist Referenzmodell f¨
ur die Klasse S genau dann, wenn R ein allgemeines Modell ist, das
• als Grundlage f¨
ur die Konstruktion spezieller Modelle der Sachverhalte der Klasse S oder
• als Vergleichsobjekt f¨
ur Modelle von Sachverhalten der Klasse S
dienen kann.“ ([Winter et al. 1999], S. 176)
Definition aus [Haux et al. 2004] Strategic Information Management in Hospitals“:
”
Model pattern for a certain class of aspects. On the one hand, these model patterns can help
”
to derive more specific models through modifications, limitations, or add-ons (generic reference
models). On the other hand, these model patterns can be used to directly compare models e.g.
concerning their comleteness (nongeneric reference models).“ ([Haux et al. 2004], S. 245)
26
3.3 Architekturstile
– Komponententypen, die die aktiven Einheiten eines Systems beschreiben und f¨
ur die
Interaktion mit anderen Komponenten Schnittstellentypen (im Original: ports“)6
”
bereitstellen,
– Konnektorentypen, die die Verkn¨
upfung von Schnittstellen und damit das Beschreiben der Interaktion von Komponenten erm¨
oglichen, und
– Konfigurationen, die das (syntaktische) Auspr¨
agen und Zusammensetzen von Komponententypen und Konnektorentypen erm¨
oglichen.
2. F¨
ur einen konkreten Architekturstil wird die Bedeutung der Elemente der Syntax durch
ein semantisches und eine Abbildung aus der Syntax in das semantische Modell festgelegt.
Durch das semantische Modell wird definiert, welche Komponententypen tats¨
achlich zu
Architekturen des betreffenden Architekturstils geh¨
oren und welche Einschr¨
ankungen es
f¨
ur die Auspr¨
agungen der Komponententypen und der Konnektorentypen sowie f¨
ur ihre
Zusammensetzung gibt.
3. Erg¨
anzend kann die Syntax f¨
ur einen bestimmten Architekturstil durch spezielle Festlegungen eingeschr¨
ankt werden, und es k¨
onnen Vereinfachungen f¨
ur bestimmte syntaktische Strukturen definiert werden.
Der in [Abowd et al. 1995] beschriebene Ansatz zur Formalisierung von Architekturen und
Architekturstilen wird u. a. in Arbeiten zur Architekturbeschreibungssprache ACME weitergef¨
uhrt (siehe z. B. [Garlan et al. 1997]).
Auf der Basis der Ausf¨
uhrungen dieses Abschnitts wird hier der Begriff Architekturstil f¨
ur
die folgenden Kapitel definiert:
Definition 3.2 Architekturstile f¨
ur Informationssystemarchitekturen werden durch
– Komponententypen,
– Konnektorentypen und
– Konfigurationen, die Komponententypen und Konnektorentypen auspr¨
agen und zusammensetzen,
beschrieben. F¨
ur die Beschreibung m¨
ussen
– eine Syntax und
– die zugeh¨
orige Semantik
¨
definiert sein. Uber
die Syntax wird festgelegt, wie Auspr¨
agungen von Komponenten und
¨
Konnektoren notiert werden. Uber
die Semantik werden die zum Architekturstil geh¨
orenden
Komponenten- und Konnektorentypen sowie Regeln f¨
ur die Bildung von Konfigurationen festgelegt.
Ende — Definition
Muster bzw. Entwurfsmuster im Sinne der am Anfang dieses Abschnitts zitierten Definitionen von Alexander bzw. Gamma entsprechen Konfigurationen im Sinne der Ausf¨
uhrungen
von [Abowd et al. 1995]. Muster k¨
onnen insofern als Architekturstile angesehen werden, als
sie i. d. R. mit einer speziellen grafischen oder textuellen Syntax definiert werden, f¨
ur die
wiederum, implizit oder explizit, eine bestimmte Semantik festgelegt wurde.
6
In [Abowd et al. 1995] wird darauf hingewiesen, dass ports“ eine Verallgemeinerung des verbreiteten Schnitt”
stellenbegriffes sind. Hier wurde die Bezeichnung Schnittstelle bzw. Schnittstellentyp beibehalten.
27
3 Informationssystemarchitekturen — Eine Einf¨
uhrung
Pipes und Filter
Komponententypen
Filter
Konnektorentypen
Pipes
Objekt-orientierte Organisation
Objekte
Ereignisbasierte,
implizite Aufrufe
Module
Funktionsaufruf,
Prozeduraufruf
Bindungen zwischen
Ereignistypen und
aufzurufenden Prozeduren
Geschichtete Systeme
Komponenten auf
den verschiedenen
Schichten
→ sind definiert in den
Protokollen f¨
ur die
Interaktion zwischen
den Ebenen
Tabelle 3.1: Beispiele f¨
ur Architekturstile (zusammengestellt aus [Shaw and Garlan 1996], Abschnitte 2.2-2.5, S. 21-25)
In [Shaw and Garlan 1996] werden Beispiele f¨
ur Architekturstile vorgestellt. Tabelle 3.1
nennt vier dieser Beispiele und die zugeh¨
origen Komponenten- und Konnektorentypen.
3.4 Architekturstile f¨
ur Informationssysteme — Metamodelle und
Referenzmodelle
Die im vorhergehenden Abschnitt referenzierte Literatur ist auf Softwaresysteme bzw. ihre
Architektur bezogen. Es wurde bereits darauf hingewiesen, dass Teile der darin enthaltenen
Ans¨
atze zur Architekturbeschreibung hier allgemeiner auf Informationssystemarchitekturen
angewendet werden. Die Verallgemeinerung besteht in der Ber¨
ucksichtigung von Aspekten, die
zun¨
achst nicht ausdr¨
ucklich auf Softwarearchitekturen bezogen sind, wie z. B. die Organisationsstruktur eines Unternehmens oder die Informationen, die in einem Unternehmen verarbeitet
werden. Ein Werk, das eine den genannten Werken vergleichbare ausf¨
uhrliche Diskussion des
Architekturbegriffes mit ausdr¨
ucklichem Bezug zu Informationssystemen enth¨
alt, war bei der
Erstellung dieser Arbeit nicht bekannt.
3.4.1 Architekturstile und Metamodelle
In semantischen Modellen von Architekturstilen werden Komponententypen und Konnektorentypen beschrieben. Das semantische Modell ist ein Metamodell f¨
ur die Beschreibung der
letztlich interessierenden Architekturen konkreter Informationssysteme (vgl. Kasten Grund”
begriffe (4)“).
Ein Beispiel f¨
ur semantische Modelle, d. h. Metamodelle, f¨
ur Informationssysteme ist das in
2
ur
der Einleitung (Kapitel A) genannte 3LGM . Es wird in Kapitel 6 vorgestellt und danach f¨
eine ausf¨
uhrliche Diskussion der Bewertung von Architekturen verwendet. Weitere Beispiele f¨
ur
Metamodelle sind das Object Model der Object Management Group (siehe Abschnitt 4.2.3)
und das Metamodell der Architektur integrierter Informationssysteme (siehe Abschnitt 4.4.2).
3.4.2 Architekturstile und Referenzmodelle
Im Zusammenhang mit Informationssystemarchitekturen wird sehr oft von Referenzmodellen
(siehe Kasten Grundbegriffe (5)“) gesprochen bzw. geschrieben. Es werden beispielsweise
”
– Vorgehens-Referenzmodelle f¨
ur die Entwicklung bzw. Weiterentwicklung von Architekturen,
28
3.4 Architekturstile f¨
ur Informationssysteme — Metamodelle und Referenzmodelle
Kasten 3.4: Grundbegriffe (5): Modelle und Referenzmodelle
Definition und Erkl¨
arung f¨
ur Informationsmodell und
Informations-Referenzmodell
Definition f¨
ur Informationsmodell aus [Becker and Sch¨
utte 1996] Handelsinformationssysteme“:
”
Ein Informationsmodell ist das immaterielle Abbild des betrieblichen Objektsystems aus Sicht
”
der in diesem verarbeiteten Informationen f¨
ur Zwecke des Informationssystem- und Organisationsgestalters.“ ([Becker and Sch¨
utte 1996], S. ????)
Informationsmodelle entsprechen konzeptionellen Datenmodellen in der Softwareentwicklung, insbesondere in der Datenbankentwicklung. Dort beschreiben konzeptionelle Datenmodelle unabh¨
angig von der Implementierungstechnik
bzw. dem verwendeten Datenbankmanagementsystem die zu verarbeitenden Informationen. Sie werden dann in technikabh¨
angige logische Datenmodelle u
uhrt (siehe z. B. [Vossen 2000], S. 72-79 (Abschnitt 4.3)).
¨berf¨
Definition: Ein Informations-Referenzmodell ist ein Informationsmodell f¨
ur eine Klasse von Informationssystemen oder von Anwendungsbereichen.
Definition f¨
ur Vorgehens-Referenzmodell
Definition aus [Lehmann and Meyer zu Bexten 2002] Handbuch der Medizinischen Informatik“ (vgl. [Winter
”
et al. 1999], S. 178):
Ein Vorgehens-Referenzmodell ist ein allgemeines Modell f¨
ur eine Klasse von Vorgehensweisen
”
z. B. bei Projekten. Aus dem Vorgehens-Referenzmodell kann die Vorgehensweise in einem speziellen Projekt z. B. in Form eines Projektplans abgeleitet werden.“ ([Lehmann and Meyer zu
Bexten 2002], S. 492)
Definition und Erkl¨
arung f¨
ur Architekturmodell und Architektur-Referenzmodell
Definition: Ein Architekturmodell im weiteren Sinn ist ein Modell, das Komponenten und ihre Beziehungen
beschreibt.
Mit der im Abschnitt 3.2 nach Definition 3.1 beschriebenen allgemeinen Auffassung von Komponenten und ihren
Beziehungen ist auch die soeben angegebene Definition sehr allgemein. Damit k¨
onnen beispielsweise auch Informationsmodelle als Architekturmodelle bezeichnet werden.
F¨
ur diese Arbeit wird der Begriff Architekturmodell hier durch die Einschr¨
ankung der Komponenten auf ausf¨
uhrbare
(oder handelnde) Komponenten bzw. auf funktionale Einheiten enger gefasst. Entsprechende Modelle werden hier als
Architekturmodelle im engeren Sinn bzw. einfach als Architekturmodelle bezeichnet:
Definition: Ein Architekturmodell im engeren Sinn ist ein Modell, das ausf¨
uhrbare oder handelnde Komponenten bzw. funktionale Einheiten und die Beziehungen zwischen den Komponenten bzw. Einheiten beschreibt.
Zu Architekturmodellen (im engeren Sinn) werden hier auch solche Modelle gerechnet, die bestimmte Funktionalit¨
aten zu funktionalen Einheiten wie z. B. Diensten oder Dienstgruppen zusammenfassen. Sie schreiben i. d. R. nicht
ausdr¨
ucklich vor, dass jede funktionale Einheit durch genau eine ausf¨
uhrbare oder handelnde Komponente des Informationssystems realisiert wird; die Abgrenzung von ausf¨
uhrbaren oder handelnden Komponenten erfolgt jedoch oft
auf der Basis von funktionalen Einheiten.
Definition: Ein Architektur-Referenzmodell ist ein Architekturmodell f¨
ur eine Klasse von Informationssystemen
oder von Anwendungsbereichen.
– Informations-Referenzmodelle f¨
ur die in bestimmten Anwendungsbereichen verarbeiteten
Informationen oder
– Architektur-Referenzmodelle f¨
ur bestimmte Aufteilungen von Informationssystemen in
ausf¨
uhrbare (oder handelnde) Komponenten
bereitgestellt.
Architektur-Referenzmodelle entsprechen Mustern bzw. konkreten Konfigurationen von Komponenten entsprechend den Ausf¨
uhrungen in Abschnitt 3.3.
29
3 Informationssystemarchitekturen — Eine Einf¨
uhrung
3.4.3 Bestimmung von Architekturstilen
In [Abowd et al. 1995] wird f¨
ur jeden der vorgestellten Architekturstile eine spezielle Semantik bzw. ein spezielles semantisches Modell beschrieben. Wenn ein semantisches Modell
sehr allgemein definiert wurde, kann es sinnvoll sein, erst im Zusammenhang mit bestimmten
Konfigurationen bzw. Mustern, die typische Komponenten und Beziehungen auspr¨
agen, von
Architekturstilen zu sprechen. Ein Architekturstil wird in diesen F¨
allen erst durch ein(e) oder
mehrere Konfigurationen bzw. Muster festgelegt. Das folgende Zitat aus [Gamma et al. 1997]
deutet am Beispiel von Mustern die Abh¨
angigkeit der Ermittlung von Architekturstilen von
bestimmten Sichtweisen oder Standpunkten an:
Die Bestimmung dessen, was ein Muster ist und was nicht, h¨
angt von der jeweiligen Perspektive ab. Was
”
aus einer Perspektive als Muster erscheint, stellt aus einer anderen Perspektive betrachtet einen primitiven
Baustein dar.“ ([Gamma et al. 1997], S. 4)
Konfigurationen bzw. Muster f¨
ur einen Architekturstil k¨
onnen in einem Architektur-Referenzmodell definiert sein.
30
4 Standards f¨
ur Informationssystemarchitekturen
4.1 Orientierung durch Rahmenwerke
Rahmenwerke f¨
ur Informationssystemarchitekturen
geben Orientierungshilfen im Dschungel“
”
– der verschiedenen Betrachtungsweisen bei der
Architekturbetrachtung,
– der Methoden und Werkzeuge f¨
ur die Systemanalyse und den Systementwurf der
– der Architekturstile mit ihren unterschiedlichen Eignungen f¨
ur bestimmte Anwendungsoder Problembereiche
– der Techniken zur Herstellung von Integration
oder
– der Vorgehensweisen f¨
ur die Durchf¨
uhrung von
Projekten im Informationsmanagement.
Einige der hier als Rahmenwerke vorgestellten Werke sind Standards, die von Organisationen wie der Internationalen Organisation f¨
ur Standardisierung (International Organization
for Standardization, ISO) oder dem Europ¨
aischen Komitee f¨
ur Normung (Comit´e Europ´een
de Normalisation, CEN) publiziert wurden. Andere sind in Organisationen, die sich aus industriellen Interessengruppen entwickelten, entstanden. Zu letzteren Organisationen geh¨
oren
beispielsweise die Object Management Group (OMG) oder The Open Group. Dabei steht die
fehlende Aufnahme eines Standards durch offizielle“ Organisationen wie der ISO oder dem
”
CEN oft nicht in Zusammenhang mit der praktischen Relevanz des betreffenden Standards,
weder positiv noch negativ.
Manche Rahmenwerke, z. B. The Open Group Architectural Framework (siehe Abschnitte 4.2.5 und 4.4.4), unterscheiden verschiedene Phasen (auch: Stufen“) f¨
ur eine Architektur”
entwicklung und stellen ein Vorgehens-Referenzmodell (siehe Kasten Grundbegriffe (5)“) zur
”
Verf¨
ugung.
Andere Rahmenwerke, z. B. das ISO Reference Model for Open Distributed Processing (siehe
Abschnitt 4.2.2), unterscheiden verschiedene Sichtweisen auf die Architektur, in denen sich
unterschiedliche Rollen bzw. Aufgaben von Personen widerspiegeln: Programmierer, die ein
Softwareprodukt erstellen, betrachten Informationssysteme anders als Rechenzentrumsleiter,
¨
die die Programmentwicklung in Auftrag geben, als Arzte
und Pflegekr¨
afte, die das Programm
zur Erleichterung von Routinet¨
atigkeiten nutzen wollen, oder als Unternehmensvorst¨
ande, die
eine Prozessoptimierung anstreben.
Die Unterscheidung von Phasen und die Unterscheidung von Sichtweisen unterst¨
utzen das
strukturierte Vorgehen beim Entwickeln oder Weiterentwickeln von Architekturen. Sie hilft den
beteiligten Personen, die eingenommenen Rollen im Entwicklungsprozess zu ermitteln und die
damit verbundenen Aufgaben abzugrenzen.
31
4 Standards f¨
ur Informationssystemarchitekturen
Auch Architektur-Referenzmodelle sind wesentlicher Bestandteil mancher Rahmenwerke,
z. B. der Object Management Architecture (siehe Abschnitt 4.2.3). Sie erleichtern die Architekturentwicklung u. a. durch Vorgaben f¨
ur die Aufteilung von Funktionalit¨
at auf Komponenten
bzw. Komponentenkategorien.
Die meisten Rahmenwerke werden erst durch zus¨
atzliche Standards oder andere Werke zu
m¨
achtigen Werkzeugen. Ben¨
otigt werden beispielsweise
– Erl¨
auterungen oder Spezifikationen f¨
ur einzelne Teile des Rahmenwerkes, z. B. die ausf¨
uhrlichen Spezifikationen f¨
ur Dienste der in der Object Management Architecture beschriebenen Schnittstellenkategorien, und
– Modellierungsmethoden bzw. -sprachen f¨
ur die Modellierung von Informationssystemen
entsprechend verschiedener Sichten oder Entwicklungsphasen, z. B. die Methode der Ereignisgesteuerten Prozessketten (EPK) oder die Unified Modeling Language (UML).
¨
Dieses Kapitel gibt einen Uberblick
u
ur Informationssystemarchi¨ ber aktuelle Rahmenwerke f¨
tekturen und mit den Rahmenwerken assoziierte Standards oder andere erg¨
anzende Werke1 .
Auf eine Beschreibung von verbreiteten Modellierungssprachen wie der UML wurde dabei verzichtet.
4.2 Technische Rahmenwerke f¨
ur Informationssystemarchitekturen
4.2.1 Das OSI-Referenzmodell der ISO
Sehr bekannt und oft zitiert ist ein von der Internationalen Organisation f¨
ur Standardisierung
(International Organization for Standardization, ISO) herausgegebenes Referenzmodell: das
Referenzmodell f¨
ur die Kopplung offener Systeme, kurz OSI-Referenzmodell (ISO-Standards
1
¨
Der Uberblick
ist durch Auswahl und Zusammenfassung entstanden. Manche hier nicht vorgestellte (Rahmen-)Werke k¨
onnen eine ¨
ahnlich große Bedeutung haben wie die vorgestellten.
Abbildung 4.1: OSI-Referenzmodell (Quelle: [ISO/IEC JTC 1 1996c], S. 28)
32
4.2 Technische Rahmenwerke f¨
ur Informationssystemarchitekturen
ISO/IEC 7498-1 bis -4: Information technology — Open Systems Interconnection — Basic Reference Model). Das OSI-Referenzmodell ist ein Architektur-Referenzmodell f¨
ur die Architektur
von Kommunikationsbeziehungen zwischen Anwendungssystemen. F¨
ur die Architekturbetrachtung sieht es sieben Schichten vor, von denen jede die Dienste der darunterliegenden Schicht
nutzt (Abbildung 4.1). Die Schichten und ihre Gegenst¨
ande sind (auszugsweise u
¨ bersetzt aus
[ISO/IEC JTC 1 1996c], S. 28 und 32-52, 7.X.2.1):
Die Anwendungssystemschicht
Gegenstand: Die Anwendungssystemschicht bildet den einzigen Weg f¨
ur Anwendungsprozesse, auf die OSIUmgebung zuzugreifen.
Die Pr¨
asentationsschicht
Gegenstand: Die Pr¨
asentationsschicht stellt die Repr¨
asentation der Informationen bereit, die Anwendungssysteme entweder kommunizieren oder auf die sie sich in ihrer Kommunikation beziehen.
Die Sitzungsschicht
Gegenstand: Zweck der Sitzungsschicht ist es, das Werkzeug bereitzustellen, welches kooperierende Pr¨
asentationseinheiten ben¨
otigen, um ihren Dialog zu organisieren und zu synchronisieren und ihren Datenaustausch zu
steuern.
Die Transportschicht
Gegenstand: Der Transportdienst sorgt f¨
ur transparente Daten¨
ubertragung zwischen Sitzungseinheiten und befreit letztere von allen Details der Art und Weise, auf welche zuverl¨
assige und kosteng¨
unstige Daten¨
ubertragung
ausgef¨
uhrt wird.
Die Netzwerkschicht
Gegenstand: Die Netzwerkschicht stellt die funktionalen und verfahrenstechnischen Mittel f¨
ur unverbundene und
¨
verbundene2 Ubermittlung
zwischen Transporteinheiten bereit und sorgt daher f¨
ur Unabh¨
angigkeit der Transporteinheiten von Routing- und Weiterleitungsbelangen.
Die Daten¨
ubertragungsschicht
Gegenstand: Die Daten¨
ubertragungsschicht stellt die funktionalen und verfahrenstechnischen Mittel f¨
ur Netzwerkeinheiten im unverbundenen Modus, f¨
ur das Aufbauen, die Aufrechterhaltung und das Abbauen von Daten¨
u
ur Netzwerkeinheiten im verbundenen Modus und f¨
ur die Ubermittlung
von daten¨bertragungsverbindungen f¨
u
¨bertragungsdienstbezogenen Datenelementen bereit.
Die physische Schicht
Gegenstand: Die physische Schicht stellt die mechanischen, elektrischen, funktionalen und verfahrenstechnischen
Mittel f¨
ur die Aktivierung, Aufrechterhaltung und Deaktivierung physischer Verbindungen zur Bit¨
ubertragung
zwischen Daten¨
ubertragungseinheiten bereit.
Die im OSI-Referenzmodell definierten Schichten stehen nicht notwendigerweise f¨
ur verschiedene Sichtweisen auf die Informationssystemarchitektur. Personen, die f¨
ur technische Details
der Kommunikation zwischen Anwendungssystemen verantwortlich sind, werden u. U. mit mehreren der Schichten in Ber¨
uhrung kommen. Die Schichten sind dann eine Hilfe zur Strukturierung des komplexen Kommunikationsthemas.
Der Standard ISO/IEC 7498-1 enth¨
alt als Grundlage f¨
ur die sieben OSI-Schichten, aber auch
f¨
ur beliebige andere schichtenorientierte Architekturen, eine ausf¨
uhrliche generische Spezifikation f¨
ur die Aufteilung von Architekturen in Schichten. Eine zentrales Konzept der Spezifikation
ist, dass jede Schicht N der u
ugung stellt,
¨ ber ihr liegenden Schicht N + 1 Dienste zur Verf¨
deren detaillierte Abwicklung der Schicht N + 1 verborgen bleibt (Abbildung 4.2; [ISO/IEC
JTC 1 1996c], Abschnitt 5).
Spezielle Standards auf der Basis des OSI-Referenzmodells
Auf der Basis des OSI-Referenzmodells wurden Standards bzw. Protokolle f¨
ur physische Komponenten, z. B. Netzwerkkabel oder Netzwerkkarten, und f¨
ur verbreitete Protokolle zum Da-
33
4 Standards f¨
ur Informationssystemarchitekturen
a)
b)
¨
Abbildung 4.2: Ubersichtsgrafik
zum generischen Schichtenkonzept (a) und Kommunikation von Einheiten der Schicht
N +1 u
¨ber die Schicht N (b) (Quelle [ISO/IEC JTC 1 1996c], S. 7-8, Figure 3 und Figure 4)
tenaustausch entwickelt, bzw. existierende Standards wurden den OSI-Schichten zugeordnet.
Hinweis: Der Begriff Protokoll bezeichnet eine Vorschrift oder einen Standard f¨
ur die Kommunikation zwischen Rechnersystemen.
F¨
ur die Daten¨
ubertragungsschicht wurden z. B. die Standards 802.X des Institute of Electrical and Electronics Engineers (IEEE) entwickelt ([WG 2001]). Der Standard 802.3 spezifiziert
beispielsweise das sogenannte Ethernet ([IEEE 802.3 WG 2002]), die Standards 802.11x spezifizieren die als Wireless LAN bekannten Techniken ([IEEE 802.11 WG 2003]).
Zur Netzwerkschicht geh¨
ort das in RFC 791 definierte Internet Protocol (IP) ([Information
Sciences Institute 1981a]).
Hinweis: Requests for Comments (RFCs) sind Spezifikationsdokumente f¨
ur viele Techniken, von
denen die meisten mit dem Internet verkn¨
upft sind. Sie werden von der Internet Engineering
Task Force (IETF) ver¨
offentlicht.
Zur Transportschicht geh¨
ort das in RFC 793 und RFC 1122 definierte Transmission Control
Protocol (TCP) ([Information Sciences Institute 1981b], [Network Working Group
1989]).
F¨
ur die Pr¨
asentationsschicht existieren Standards f¨
ur Text- und Bilddaten wie der American
ISO OSI−Referenzmodell
TCP/IP−Schichtenmodell
Anwendung
Anwendung
Darstellung
Kommunikationssteuerung
Transport
Vermittlung
Transport
IP
Datensicherung
Sicherung
Physikalisch
Physikalisch
Abbildung 4.3: OSI- und TCP/IP-Schichtenmodelle (nach [Washburn and Evans 1994], S. 9, 157)
34
4.2 Technische Rahmenwerke f¨
ur Informationssystemarchitekturen
Standard Code for Information Interchange (ASCII) und seine Erweiterungen (z. B. [ISO JTC
1 1998]), das Tagged Image File Format (TIFF) ([ISO TC 130 2004]) oder die Standards der
Moving Picture Experts Group (MPEG) ([ISO JTC 1 1993]).
Der Anwendungsebene k¨
onnen anwendungsbereichsunabh¨
angige Standards bzw. Protokolle,
z. B. Telnet (RFC 854), das File Transfer Protocol (FTP) (RFC 959), das Hypertext Transfer
Protocol (HTTP) ([Network Working Group 1999]) oder der Kerberos Network Authentication Service (1510), aber auch anwendungsbereichsabh¨
angige Kommunikationsstandards,
z. B. Health Level Seven (HL7) ([HL7 1999]), zugeordnet werden.
F¨
ur die verbreitet genutzten Protokolle TCP und IP wird oft auch eine alternative Aufteilung
in Schichten angegeben (Abbildung 4.3).
Integrationsanforderungen und das OSI-Referenzmodell
Die Standards zu den Schichten des OSI-Referenzmodells beschreiben Techniken f¨
ur physische
Integration, d. h. f¨
ur physische Netzwerkkomponenten wie Netzwerkkarten oder Router, und
grundlegende Techniken f¨
ur Datenintegration. Letztere sind Voraussetzung f¨
ur die Realisierung
von Kommunikationsbeziehungen f¨
ur spezielle Anwendungssysteme.
Der als Beispiel genannte Standard HL7 wurde unmittelbar f¨
ur Datenintegration im Gesundheitswesen entwickelt.
4.2.2 Das Referenzmodell f¨
ur offene verteilte Informationsverarbeitung der ISO
Die ISO-Standards ISO/IEC 10746-1 bis -4: Information technology — Open Distributed
Processing — Reference model wurden f¨
ur die Erstellung von Spezifikationen f¨
ur Informationssysteme herausgegeben, die verteilte Informationsverarbeitung erm¨
oglichen und dabei als
offen charakterisiert werden. Sie enthalten umfassende Empfehlungen f¨
ur die Analyse, den Entwurf und die Bewertung von verteilten Informationssystemen ([ISO/IEC JTC 1 1998b]). Die
Standards werden auch als das Referenzmodell f¨
ur offene verteilte Informationsverarbeitung
¨
(Reference Model for Open Distributed Processing, RM-ODP) bezeichnet (Kasten Uberblick
”
u
ber
Standards
zum
Referenzmodell
.
.
.“).
¨
Die RM-ODP-Standards werden erg¨
anzt durch weitere ISO-Standards, wie z. B. ISO/IEC
13235-X, die viele der in den RM-ODP-Standards zusammenfassend beschriebenen Komponenten bzw. Eigenschaften von Komponenten ausf¨
uhrlich spezifizieren (Kasten Erg¨
anzende
”
Standards zum RM-ODP . . .“).
Grundlagen f¨
ur die Beschreibung von offener verteilter Informationsverarbeitung
Der Standard ISO/IEC 10746-2 ([ISO/IEC JTC 1 1996b]) definiert die in den u
¨ brigen ODPStandards f¨
ur die Architekturbeschreibung verwendeten Begriffe. Dazu geh¨
ort u. a. der Begriff
Objekt (object):
Object: A model of an entity. An object is characterized by its behaviour (. . . ) and, dually, by its state
”
(. . . ). (. . . ) An object is encapsulated, i. e. any change in its state can only occur as a result of an internal
action or as a result of an interaction (. . . ) with its environment (. . . ).“ ([ISO/IEC JTC 1 1996b], S. 3)
Das Zusammenwirken von Objekten geschieht u
¨ ber Interaktionen (interactions). Die Interaktionen, an denen ein Ojekt teilnehmen kann, werden u
¨ ber Schnittstellen (interfaces) zusammengefasst:
35
4 Standards f¨
ur Informationssystemarchitekturen
¨
Kasten 4.1: Uberblick
u
¨ber ISO-Standards zum RM-ODP
¨
ISO/IEC 10746-1: Overview gibt einen Uberblick
u
¨ber die RM-ODP-Standards.
Auszug aus [ISO/IEC JTC 1 1998b], S. 8:
6.2.1 Object modelling
”
Object modelling provides a formalization of well-established design practices of abstraction and
encapsulation. (. . . )
The object modelling concepts cover:
• Basic modelling concepts – Providing rigorous definitions of a minimum set of concepts
(action, object. interaction and interface) that form the basis for ODP system descriptions
and are applicable in all viewpoints.
• Specification concepts – Addressing notions such as type and class that are necessary for
reasoning about specifications and the relations between specifications, provide general tools
for design, and establish requirements on specification languages.
• Structuring concepts – Building on the basic modelling concepts and the specification concepts to address recurrent structures in distributed systems, and cover such concerns as
policy, naming, behaviour, dependability and communication.
(. . . )“
ISO/IEC 10746-2: Foundations beschreibt allgemeine Begriffe zur Beschreibung verteilter Informationssysteme;
dazu geh¨
oren u. a. der Begriff object sowie u. a. Begriffe zur Spezifikation von Objekten (z. B. composition,
refinement, type, class), zur Organisation von Objekten (z. B. configuration, domain) oder zur Spezifikation
von Eigenschaften von Systemen oder Objekten (z. B. distribution transparency, contract).
Ausz¨
uge aus [ISO/IEC JTC 1 1996b], S. 3 und 5:
8.1 Object: A model of an entity. An object is characterized by its behaviour (. . . ) and, dually,
”
by its state (. . . ). An object is distinct from any other object. An object is encapsulated, i.e. any
change in its state can only occur as a result of an internal action or as a result of an interaction
(. . . ) with its environment (. . . ).“
9.1 Composition
”
a) (Of objects) – A combination of two or more objects yielding a new object, at a different
level of abstraction. The characteristics of the new object are determined by the objects being
combined and by the way they are combined. The behaviour of a composite object is the
corresponding composition of the behaviour of the component objects.
(. . . )“
Action: Something which happens.
”
Every action of interest for modelling purposes is associated with at least one object.
The set of actions associated with an object is partitioned into internal actions and interactions.“
([ISO/IEC JTC 1 1996b], S. 4)
Interface: An abstraction of the behaviour of an object that consists of a subset of the interactions of
”
that object together with a set of constraints on when they may occur.“ ([ISO/IEC JTC 1 1996b], S. 4)
Der Standard definiert viele weitere Begriffe f¨
ur die detaillierte Beschreibung von Objekten
und ihren Interaktionen (siehe auch Kasten Erg¨
anzende Standards zum RM-ODP . . .“).
”
Das Referenzmodell
Die wichtigsten Ans¨
atze zur Informationssystemarchitekturbetrachtung in den RM-ODP-Standards enth¨
alt ISO/IEC 10746-3 ([ISO/IEC JTC 1 1996a]). Das sind
– die Unterscheidung von verschiedenen Sichtweisen und
36
4.2 Technische Rahmenwerke f¨
ur Informationssystemarchitekturen
¨
Kasten 4.2: Uberblick
u
¨ber ISO-Standards zum RM-ODP (Fortsetzung)
ISO/IEC 10746-3: Architecture spezifiziert auf der Basis von ISO/IEC 10746-2 Charakteristika offener verteilter
Informationssysteme. Zum Standard geh¨
oren u. a.
– die Unterscheidung verschiedener Sichtweisen (z. B. enterprise viewpoint, information viewpoint),
– den Sichtweisen zugeh¨
orige Sprachen,
– die Beschreibung von Funktionen, die in offenen verteilten Informationssystemen implementiert sein
m¨
ussen (z. B. thread management, recovery), und
– die Beschreibung von Transparenzen, durch die bestimmte Systemeigenschaften verborgen werden (z. B.
location transparency, persistence transparency).
Auszug aus [ISO/IEC JTC 1 1996a], S. 7:
5 Enterprise language
”
The enterprise laguage comprises concepts, rules and structures for the specification of an ODP
system from the enterprise viewpoint. (. . . )
5.1 Concepts
The enterprise language contains the concepts of ITU-T Rec. X.902 | ISO/IEC 10746-2 and those
defined here, subject to the rules of 5.2.
5.1.1 Community: A configuration of objects formed to meet an objective. The objective is
expressed as a contract which specifies how the objective can be met.
5.1.2 <X> federation: A community of <x> domains.“
ISO/IEC 10746-4: Architectural semantics formalisiert die Bedeutungen der in den Abschnitten 8 und 9
von ISO/IEC 10746-2 definierten Begriffe unter Nutzung verschiedener formaler Beschreibungssprachen (z. B.
LOTOS, Z ).
Auszug aus [ISO/IEC JTC 1 1998a], S. 5:
4.1.2.1 Composition
”
– of objects A composite object is an object described through the application of one or
more LOTOS combination operators. These include:
· interleaving operator (|||);
· parallel composition operators (|| and |[gate-list]|);
· enabling operator (≫);
· disabling operator ([>);
· choice operator ([])
(. . . )“
– die Definition je einer Architektur-Beschreibungssprache f¨
ur jede Sichtweise.
Die Sichten sind (¨
ubersetzt aus [ISO/IEC JTC 1 1996a], S. 4):
Die Unternehmenssichtweise: Eine Sichtweise auf das System und seine Umgebung, die den
Zweck, den Anwendungsbereich und die Verfahrensweisen des Systems in den Mittelpunkt
stellt.
Die Informationssichtweise: Eine Sichtweise auf das System und seine Umgebung, die die
Semantik der Informationen und ihre Verarbeitung in den Mittelpunkt stellt.
Die rechnerbezogene Sichtweise: Eine Sichtweise auf das System und seine Umgebung,
die eine Verteilung durch funktionale Zerlegung in Objekte, die u
¨ ber Schnittstellen interagieren, erm¨
oglicht.
Die Konstruktionssichtweise: Eine Sichtweise auf das System und seine Umgebung, die
37
4 Standards f¨
ur Informationssystemarchitekturen
die Mechanismen und Funktionen f¨
ur eine verteilte Interaktion zwischen Objekten im
System in den Mittelpunkt stellt.
Die technologische Sichtweise: Eine Sichtweise auf das System und seine Umgebung, die
die gew¨
ahlte(n) Technologie(n) in den Mittelpunkt stellt.
Der Standard definiert außerdem
– Funktionen, die ein verteiltes Informationssystem als offen charakterisieren, und
– Transparenzen, durch die die Verteilung des Informationssystems vor seinen Nutzern und
vor Entwicklern anwendungsspezifischer Komponenten verborgen wird.
Die Funktionen sind dabei in die vier Gruppen Management (management), Koordination
(coordination), Verzeichnis (repository) und Sicherheit (security) aufgeteilt. Beispiele sind die
Funktion Objektmanagement (object management) in der Gruppe Management und die Funktion Handel (trading) in der Gruppe Verzeichnis. Die Transparenzen sind Zugriffstransparenz
(access transparency), Ausfalltransparenz (failure t.), Ortstransparenz (location t.), Migrationstransparenz (migration t.), Speichertransparenz (persistence t.), Verlagerungstransparenz (relocation t.), Replikationstransparenz (replication t.) und Transaktionstranzparenz (transaction
t.).
Spezielle Standards auf der Basis des RM-ODP
Im Standard ISO/IEC 10746-3 selbst sind die Funktionen und Transparenzen NICHT in den
Sprachen der verschiedenen Sichtweisen definiert, sondern haupts¨
achlich in kurzen Beschreibungstexten bez¨
uglich wesentlicher Begriffe und Regeln dargestellt. Eine ausf¨
uhrliche sichtweisenbezogene Definition der Funktionen wird in zus¨
atzlichen Standards gegeben, z. B. ISO/IEC
13235-1 bis -3 f¨
ur die in ISO/IEC 10746-3 vorgesehene Trading Function (Kasten Erg¨
anzen”
de Standards zum RM-ODP: . . .“; [ISO/IEC JTC 1 1995]). F¨
ur die Transparenzen existieren
keine ausf¨
uhrlichen sichtweisenbezogenen Standards.
Integrationsanforderungen und das RM-ODP
Das RM-ODP beschreibt Grundlagen f¨
ur den Entwurf verteilter Informationssysteme. Auch
wenn einige der im Standard beschriebenen Konzepte prinzipiell auch f¨
ur konventionelle papierbasierte Informationsverarbeitung anwendbar sind, ist der Standard auf den Entwurf von
Softwaresystemen ausgerichtet.
Die mit dem RM-ODP definierten Begriffe bilden eine generische Terminologie f¨
ur die Beschreibung verteilter Informationssysteme. Sie k¨
onnen f¨
ur viele rechnerbasierte Integrationstechniken zur Erf¨
ullung unterschiedlicher Integrationsanforderungen angewendet werden.
Die im RM-ODP beschriebenen speziellen Funktionen, die in einem verteilten System implementiert sein sollten, werden in den genannten erg¨
anzenden Standards spezifiziert. Sie k¨
onnen
als spezielle Techniken zur Verwaltung der Verteilung betrachtet werden.
38
4.2 Technische Rahmenwerke f¨
ur Informationssystemarchitekturen
Kasten 4.3: Erg¨
anzende Standards zum RM-ODP: Spezifikation der in
ISO/IEC 10746-3 vorgesehenen Trading Function in Standard ISO/IEC
13235-1 (Ausz¨
uge)
6. Enterprise Specification of the
Trading Function (. . . )
”
6.1 Communities
The communities are:
6.1.1 trading community - a community of objects
established for the purpose of trading and governed by
a trading policy. (. . . )
6.2 Roles
Objects may play the following roles within a trading
community:
6.2.1 trader - a role which registers service offers
from exporter objects and returns service offers upon
request to importer objects according to some criteria. (. . . )
6.3 Activities
The following activities are relevant to a trading community:
6.3.1 service export - a chain of actions by an exporter object and the trader object which establish
and terminate a liaison in which the trader object is
permitted to provide the exporter object’s service offer to a group of importer objects. (. . . )
6.4 Policies
The activities of an ODP Trading system are governed by policy. (. . . )
6.4.1 Export policy
Export policy is a set of rules related to the service
export activity (. . . ).
The policy may include, amongst other things:
· an obligation for a service offer to be described in a
specific way;
· a prohibition of specified service import activities
from discovering the service offer;
· a permission for the service export to be propogated
to an interworking trading community. (. . . )
6.5 Structuring Rules (. . . )
6.5.2 Transfer Rules
Exporter objects can export offers for services which
they provide at their own interfaces, or may export
offers for services provided by a distinct service provider object. (. . . )
7. Information Specification of the
Trading Function (. . . )
7.2 Basic Concepts (. . . )
7.2.3 Service Description
A service description is at least an interface signature
type. It can also include a set of service properties.
Service properties contain information about computational aspects (. . . ) as well as describing the technology, engineering, information, and enterprise aspects
of the service.
The formal definition of service description is given in
the Z schema ServiceDescription. (. . . )
7.3 Invariant Schema The components of the trading system are:
· A set (offers) of service offers which are available for
import;
· A set (nodes) of nodes into which these service offers
are partitioned;
· A relationship (edges) between nodes to represent
the edges of the trading graph, which governs the propagation of searches;
· Sets (edge properties) of properties which are associated with the edges.(. . . )
(. . . )
8. Computational Specification of
the Trading Function (. . . )
8.2 Trading operation parameter types
8.2.1 Interface identifier type
The interface identifier type is a union with an CORBA Object reference choice arm, and an extension
choice arm of type any. (. . . )
8.4 Standard Properties
8.4.1 Standard Service Offer Properties
8.4.1.1 Expiry date
“expiry date”, a service offer property (. . . ) “
([ISO/IEC JTC 1 1995], S. 5 ff.)
39
4 Standards f¨
ur Informationssystemarchitekturen
4.2.3 Die Object Management Architecture
Innerhalb der zur¨
uck liegenden etwa zehn Jahre3 hat sich die Common Object Request Broker
Architecture (CORBA) der Object Management Group (OMG) zu einem bekannten Standard
entwickelt ([OMG 2004]). In Vortr¨
agen und Publikationen, sogar in denen der OMG selbst,
wird dabei selten auf das der CORBA zugrunde liegende Rahmenwerk, die Object Management
¨
Architecture (OMG OMA), hingewiesen (Kasten Uberblick
u
¨ ber OMG-Standards . . .“; [OMG
”
1997]).
Den Kern“ der OMA bilden
”
– das OMG Object Model, ein Metamodell f¨
ur die Beschreibung von objektbasierten Informationssystemen, und
– das OMA Reference Model, ein Architektur-Referenzmodell f¨
ur die Aufteilung von Komponenten eines Informationssystems in Schnittstellenkategorien und eine Vermittlungskomponente.
Das OMG Object Model und das OMG Component Model
Das OMG Object Model definiert als Metamodell Begriffe f¨
ur die Beschreibung von objektbasierten Informationssystemen. Der zentrale Begriff ist Objekt. Ein Objekt ist nach dem OMG
Object Model eine Komponente eines Informationssystems, die anderen Komponenten Dienste,
d. h. eine bestimmte Funktionalit¨
at, zur Verf¨
ugung stellt:
An object is an identifiable, encapsulated entity that provides one or more services that can be requested
”
by a client.“ ([OMG 1997], S. 3-2)
Es werden weitere Begriffe zur genaueren Spezifikation von Objekten definiert. Dazu geh¨
oren
u. a. Anfrage (request), Typ (type), Schnittstelle (interface) und Operation (operation). Eine
Schnittstelle ist beispielsweise nach dem OMG Object Model eine Beschreibung einer Menge
von Operationen, die bei einem Objekt von anderen Komponenten angefordert werden k¨
onnen,
d. h. die anderen Komponenten zur Verf¨
ugung gestellt werden:
An interface is a description of a set of possible operations that a client may request of an object. An
”
object satisfies an interface if it can be specified as the target object in each potential request described
by the interface.“ ([OMG 1997], S. 3-5)
Eine Operation ist eine abgrenzbare Einheit, die einen bestimmten Dienst, d. h. eine bestimmte
Funktionalit¨
at, bezeichnet:
An operation is an identifiable entity that denotes a service that can be requested.“ ([OMG 1997], S. 3-5)
”
Der Begriff Operation kann dabei als Pr¨
azisierung des im RM-ODP verwendeten allgemeinen
Interaktionsbegriffes verstanden werden (vgl. Abschnitt 4.2.2).
Das OMG Object Model definiert außerdem Begriffe zur Beschreibung der Implementierung
von Objekten. Dazu geh¨
ort u. a. der Begriff Methode:
Code that is executed to perform a service is called a method. A method is an immutable description of a
”
computation that can be interpreted by an execution engine.“ ([OMG 1997], S. 3-8)
Allein mit den Begriffen des OMG Object Models kann das Zusammenwirken von Komponenten eines Informationssystems nicht oder nur grob beschrieben werden. Haupts¨
achlich deshalb wurde das OMG Object Model nachtr¨
aglich durch das OMG Component Model erweitert
3
Die Anf¨
ange der CORBA-Spezifikation liegen m¨
oglicherweise noch l¨
anger zur¨
uck.
40
4.2 Technische Rahmenwerke f¨
ur Informationssystemarchitekturen
Abbildung 4.4: Das Object Management Architecture Reference Model (Quelle: [OMG 1997], Abb. 4-1)
([OMG 2002a]). Darin wird der Begriff Komponente als Spezialisierung und gleichzeitige Erweiterung von Objekt eingef¨
uhrt. Das OMG Component Model f¨
uhrt mit dieser Erweiterung
zus¨
atzliche Begriffe ein, mit denen haupts¨
achlich das Zusammenwirken von Komponenten spezifiziert werden kann. Beispiele sind die Begriffe Verbindung (connection), Verbindungspunkte
(receptacles), Ereignistyp (event type), Ereignisquelle (event source), Ereignissenke (event sink),
Komponentenheimat (component home) oder Komponentenkonfiguration (component configuration). Zu den meisten Begriffen des OMG Component Models werden Schnittstellen spezifiziert, z. B. f¨
ur das Erzeugen von Objektinstanzen, das Empfangen von Ereignissen usw.
Damit geh¨
ort das OMG Component Model zu den Spezifikationen von gemeinsamen Diensten
im Sinne des nachfolgend vorgestellten OMA Reference Model.
F¨
ur die formale Spezifikation von Objekten bzw. Komponenten auf der Basis der im OMG
Object Model und im OMG Component Model definierten Begriffe wurde die Interface Definition Language (OMG IDL) entwickelt. Sie ist in Kapitel 3 der CORBA-Spezifikation definiert
([OMG 2004], S. 3-1 - 3-74).
Das Object Management Architecture Reference Model
Am Anfang dieses Abschnitts wurde neben dem OMG Object Model als Metamodell auch das
Object Management Architecture Reference Model (OMA Reference Model) als ArchitekturReferenzmodell eingef¨
uhrt (Abbildung 4.4). Sie beschreibt
– eine zentrale Komponente, den Object Request Broker (ORB), der die Kommunikation von Objekten und ihren Auftraggebern“ erm¨
oglicht und
”
– vier Kategorien, in die Objekte bzw. ihre Schnittstellen auf der Basis der Dienste, die
durch die von ihnen bereitgestellten Operationen repr¨
asentiert werden, eingeteilt werden
k¨
onnen.
Die Kategorien werden folgendermaßen abgegrenzt (¨
ubersetzt aus [OMG 1997], Abschnitt
4.1.2, S. 4-1 - 4-2, siehe auch die ausf¨
uhrlicheren Beschreibungen in [OMG 1997], Abschnit-
41
4 Standards f¨
ur Informationssystemarchitekturen
te 4.1.5-4.1.7, S. 4-3 - 4-4):
Objektdienste (object services) sind Schnittstellen f¨
ur allgemeine Dienste, die in voraussichtlich jedem Programm,
das auf verteilten Objekten basiert, genutzt werden.
Gemeinsame Dienste (common facilities) sind Schnittstellen f¨
ur horizontale benutzerorientierte Dienste, die in den
meisten Anwendungsbereichen ben¨
otigt werden.
Anwendungsbereichsschnittstellen (domain interfaces) sind spezifische Schnittstellen f¨
ur einen bestimmten Anwendungsbereich.
Anwendungssystemschnittstellen (application interfaces) sind nicht-standardisierte, anwendungssystemspezifische Schnittstellen.
Spezielle Standards auf der Basis der OMA
Die zentrale Komponente der OMA, der ORB, wird in einem umfangreichen Standard, der
Common Object Request Broker Architecture (CORBA), spezifiziert ([OMG 2004]). Im CORBA-Standard wird u. a. auch die Interface Definition Language (IDL) f¨
ur die Spezifikation
der Schnittstellen des ORB aber auch f¨
ur weitere Schnittstellenspezifikationen in erg¨
anzenden
Standards der OMG definiert.
Im Gegensatz zu den u
ur die Objektdiens¨ brigen Dienst- bzw. Schnittstellenkategorien wird f¨
te bereits mit dem OMA Reference Model nicht nur eine allgemeine Abgrenzung vorgenommen,
sondern genauer beschrieben, welche Funktionalit¨
at u
ugung
¨ ber welche Objektdienste zur Verf¨
gestellt wird ([OMG 1997], S. 4-7 - 4-12). Eine ausf¨
uhrliche Spezifikation der Objektdienste wird jedoch in weiteren Dokumenten der OMG vorgenommen. Beispiele f¨
ur Objektdienste
sind
– der Trading Object Service f¨
ur das Anbieten und Finden von Diensten ([OMG 2000f]),
– der Persistent State Service f¨
ur das Speichern von Objekten ([OMG 2002c]) oder
– der Security Service f¨
ur das Sch¨
utzen von Informationen ([OMG 2002d]).
Auch f¨
ur die Kategorie der gemeinsamen Dienste und insbesondere f¨
ur die Kategorie der Anwendungsbereichsschnittstellen wurden von der OMG Spezifikationsdokumente f¨
ur einzelne
Dienste herausgegeben. Beispiele f¨
ur gemeinsame Dienste sind
¨
– die Meta-Object Facility ([OMG 2000d]; siehe auch Kasten ”Uberblick
u
¨ber OMG-Standards zur . . .“),
– die Internationalization, Time Operations, and Related Facilities ([OMG 2000c]) und
– die Mobile Agent Facility ([OMG 2000e]).
Beispiele f¨
ur Anwendungsbereichsschnittstellen sind
– f¨
ur den Anwendungsbereich Transportwesen
· die Air Traffic Control Specification ([OMG 2000a]),
– f¨
ur den Anwendungsbereich Finanzen
· die Currency Specification ([OMG 2000b]),
– f¨
ur den Anwendungsbereich Biowissenschaften
· die Biomolecular Sequence Analysis Specification ([OMG 2001a]),
· die Gene Expression Specification ([OMG 2003a]),
· die Genomic Maps Specification ([OMG 2002b]) und
– f¨
ur den Anwendungsbereich Gesundheitswesen
42
4.2 Technische Rahmenwerke f¨
ur Informationssystemarchitekturen
MDA-Sichtweisen
rechnerunabh¨
angige Sichtweise
plattformunabh¨
angige Sichtweise
plattformspezifische Sichtweise
RM-ODP-Sichtweisen
Unternehmenssichtweise
Informationssichtweise
Unternehmenssichtweise
Informationssichtweise
rechnerbezogene Sichtweise
(Konstruktionssichtweise)*
(technologische Sichtweise)*
* Die Zuordnung der Konstruktionssichtweise und der technologischen Sichtweise des
RM-ODP zur plattformspezifischen Sichtweise des MDA Guide ist im MDA Guide
nicht dokumentiert. Sie wurde vom Autor dieser Arbeit erg¨
anzt.
Tabelle 4.1: Zuordnung von RM-ODP-Sichtweisen zu MDA-Sichtweisen (Quelle: [OMG 2003b], S. 3-1 - 3-2)
· die Clinical Observations Access Service Specification ([OMG 2001b]),
· die Person Identification Service Specification ([OMG 2001c]) und
· die Resource Access Decision Facility Specification ([OMG 2001d]).
F¨
ur Anwendungssystemschnittstellen wurden von der OMG keine Standards herausgegeben.
Zu dieser Kategorie geh¨
oren die Schnittstellen, die nicht in einem Standard spezifiziert werden
k¨
onnen, sondern die auf bestimmte konkrete Anwendungsszenarios zugeschnitten sind.
Model Driven Architecture
Die bisher in diesem Abschnitt beschriebenen Standards sind unmittelbar auf die OMA bezogen. Sie werden erg¨
anzt durch den Model Driven Architecture Guide (MDA Guide), der
eine Anleitung, d. h. ein Vorgehens-Referenzmodell, f¨
ur die Verwendung von Modellen bei der
Softwareentwicklung enth¨
alt.
Der MDA Guide definiert zuerst grundlegende Begriffe im Zusammenhang mit der Modellierung, z. B. Modell (model), Architektur (architecture), Sichtweise (viewpoint), Sicht (view)
oder Plattform (platform). Die Definition f¨
ur Sichtweise ist beispielsweise:
A viewpoint on a system is a technique for abstraction using a selected set of architectural concepts and
”
structuring rules, in order to focus on particular concerns within that system. Here ‘abstraction’ is used to
mean the process of suppressing selected detail to establish a simplified model.“ ([OMG 2003b], S. 2-3)
Hier sei der Begriff Plattform hervorgehoben, der wesentliches sprachliches Hilfsmittel f¨
ur die
Abgrenzung von Abstraktionsschichten bei der Aufteilung von Informationssystemen in Komponenten ist:
A platform is a set of subsystems and technologies that provide a coherent set of functionality through
”
interfaces and specified usage patterns, which any application supported by that platform can use without
concern for the details of how the functionality provided by the platform is implemented.“ ([OMG 2003b],
S. 2-3)
Der Plattformbegriff wird u. a. auch im TOGAF Technical Reference Model (siehe Abschnitt
4.2.5) verwendet.
Unter Nutzung des Plattformbegriffes beschreibt der MDA Guide drei Sichtweisen auf Systeme (¨
ubersetzt aus [OMG 2003b], S. 2-5):
43
4 Standards f¨
ur Informationssystemarchitekturen
a)
b)
ist das Plattform-Symbol im MDA-Kontext
Abbildung 4.5: Das Model Driven Architecture Pattern (a) (Quelle: [OMG 2003b], Abb. 2-2) und generische Unterscheidung von Sichtweisen auf Plattformen (b) (Quelle: [OMG 2003b], Abb. 6-6)
Die rechnerunabh¨
angige Sichtweise (computation independent viewpoint) ist auf die Umgebung des betrachteten Systems und auf die Anforderungen an das System gerichtet; die Details der Struktur und der Prozesse des
Systems sind verborgen oder sogar unbestimmt.
Die plattformunabh¨
angige Sichtweise (platform independent viewpoint) ist auf die Arbeitsweise des betrachteten Systems gerichtet, wobei die Details, die bestimmte Plattformen betreffen, verborgen bleiben. Eine plattformunabh¨
angige Sicht zeigt den Teil der vollst¨
andigen Spezifikation, der sich zwischen verschiedenen Plattformen
nicht ¨
andert.
Die plattformspezifische Sichtweise (platform specific viewpoint) auf das betrachtete System kombiniert die
plattformunabh¨
angige Sichtweise mit der zus¨
atzlichen Ber¨
ucksichtigung der Details der Verwendung einer bestimmten Plattform durch das System.
Modelle werden als Sichten auf Systeme aufgefasst. Entsprechend den Sichtweisen f¨
uhrt der
MDA Guide die Kategorien
– rechnerunabh¨
angige Modelle (computation independent models, CIM),
– plattformunabh¨
angige Modelle (platform independent models, PIM) und
– plattformspezifische Modelle (platform specific models, PSM)
ein, erg¨
anzt um eine zus¨
atzliche Kategorie f¨
ur
– Plattformmodelle (platform models).
Die Vorgehens-Beschreibung im MDA Guide ordnet den MDA-Sichtweisen Sichtweisen aus
dem RM-ODP zu (Tabelle 4.1, vgl. Abschnitt 4.2.2; [OMG 2003b], S. 3-1 - 3-2). Den gr¨
oßten
Teil des MDA Guide nehmen Beschreibungen von Transformationen von Modellen und zugrunde liegenden Metamodellen ein. Der Schwerpunkt liegt dabei auf der Transformation von
plattformunabh¨
angigen Modellen in plattformabh¨
angige Modelle. In diesem Zusammanhang
wird das MDA-Muster (MDA pattern) eingef¨
uhrt (Abbildung 4.5a).
¨
An dieser Stelle sei auf die Ahnlichkeit der generischen Plattformbetrachtung im MDA
Guide ([OMG 2003b], S. 6-1 - 6-6) und des generischen Schichtenkonzeptes, das dem OSIReferenzmodell zugrunde liegt (vgl. Abschnitt 4.2.1), hingewiesen. Dazu wird im MDA Guide
das Prinzip beschrieben, Plattformen aus verschiedenen u
¨ bereinander liegenden“ Sichtweisen
”
zu betrachten, wobei die Details bzgl. der unteren Sichtweisen jeweils den dar¨
uber liegenden
Sichtweisen verborgen bleiben (Abbildung 4.5b).
44
4.2 Technische Rahmenwerke f¨
ur Informationssystemarchitekturen
¨
Kasten 4.4: Uberblick
u
¨ber OMG-Standards zur Architekturentwicklung
Die Object Management Architecture (OMA) ist der grundlegende Rahmen f¨
ur die Entwicklung verteilter
objektbasierter Informationssysteme ([OMG 1997]). Sie enth¨
alt
– das OMG Object Model, ein Metamodell f¨
ur die Beschreibung von objektbasierten Informationssystemen, und
– das Object Management Architecture Reference Model (OMA Reference Model), ein ArchitekturReferenzmodell mit
· der zentralen Vermittlungskomponente, dem Object Request Broker (ORB), und
· den vier Schnittstellenkategorien Objektdienste, gemeinsame Dienste, Anwendungsbereichsschnittstellen und Anwendungssystemschnittstellen.
Die Common Object Request Broker Architecture (CORBA) spezifiziert die zentrale Komponente der
OMA, den ORB ([OMG 2004]). Im CORBA-Standard wird auch die Interface Definition Language (IDL)
f¨
ur die Spezifikation von Schnittstellen definiert. Die IDL wird f¨
ur die Spezifikation des ORB sowie in allen
weiteren OMG-Dokumenten, die Schnittstellen spezifizieren, verwendet, z. B. f¨
ur die Objektdienste und die
gemeinsamen Dienste.
F¨
ur die Schnittstellenkategorien Objektdienste, gemeinsame Dienste und Anwendungsbereichsschnittstellen der OMA
wurden verschiedene Spezifikationsdokumente f¨
ur einzelne Dienste herausgegeben. Beispiele sind:
– der Trading Object Service f¨
ur das Anbieten und finden von Diensten ([OMG 2000f]; Kategorie
Objektdienste).
– die Internationalization, Time Operations, and Related Facilities f¨
ur das Anbieten und finden
von Diensten ([OMG 2000c]; Kategorie gemeinsame Dienste).
– die Clinical Observations Access Service Specification f¨
ur den Zugriff auf Befunde und andere Resultate medizinischer Unteruchungen ([OMG 2001b]; Kategorie Anwendungsbereichsschnittstellen,
Anwendungsbereich Gesundheitswesen).
Der Model Driven Architecture Guide (MDA Guide) ist, unabh¨
angig von der OMA, eine Anleitung f¨
ur die
Verwendung von Modellen bei der Softwareentwicklung ([OMG 2003b]). Darin werden grundlegende Begriffe
f¨
ur die Modellierung, wie z. B. Modell (model), Architektur (architecture), Sichtweise (viewpoint), Sicht (view)
oder Plattform (platform), definiert.
Der MDA Guide beschreibt außerdem drei Sichtweisen auf Systeme:
– die rechnerunabh¨
angige Sichtweise (computation independent viewpoint),
– die plattformunabh¨
angige Sichtweise (platform independent viewpoint) und
– die plattformspezifische Sichtweise (platform specific viewpoint).
Der gr¨
oßte Teil des MDA Guide beschreibt Modelltransformationen, haupts¨
achlich f¨
ur Transformationen plattformunabh¨
angiger Modelle in plattformspezifische Modelle.
OMG-Standards zur Umsetzung des MDA Guide sind ([OMG 2003b], S. 7-1 - 7-2)
– die Unified Modeling Language (UML), die sich auch außerhalb der OMG-Standards als universelle
Modellierungssprache f¨
ur Informationssystemarchitekturen, Softwareentw¨
urfe und viele weitere andere
Aspekte der Informationsverarbeitung durchgesetzt hat ([OMG 2003c]),
– die umfangreiche Meta-Object Facility (MOF) Technology zur Erstellung und Verwaltung von
Modellen und Metamodellen und zur Wahrung der Konsistenz zwischen Modellen und Metamodellen
([OMG 2000d]),
– die Profile f¨
ur die Spezifikation neuer Modellierungssprachen auf der Basis der UML ([OMG 2003c],
Abschnitt 2.6 Extension Mechanisms“) und
”
– Spezifikationen verschiedener Plattformen, z. B. Realtime CORBA, CORBA Components oder die
anwendungsbereichsspezifischen Dienste f¨
ur das Gesundheitswesen.
Die MOF ist gleichzeitig ein Beispiel f¨
ur Common Facilities entsprechend der OMA.
Hinweis: Die Reihenfolge der Standards entspricht nicht in jedem Fall der zeitlichen Reihenfolge ihrer Ver¨
offentlichung.
45
4 Standards f¨
ur Informationssystemarchitekturen
Integrationsanforderungen und die OMA
Die OMA wurde, wie das RM-ODP, f¨
ur den Entwurf verteilter Informationssysteme entwickelt.
Sie ist jedoch spezieller auf die Bereitstellung von Diensten durch Komponenten ausgerichtet.
Mit der CORBA wird eine Komponente f¨
ur die Vermittlung von Dienstanforderungen an Komponenten und die Bereitstellung der Ergebnisse der Dienstanforderungen spezifiziert.
Die OMA und insbesondere die CORBA spezifizieren folglich eine Technik f¨
ur die funktionale Integration. Wegen der in Abschnitt 2.2.3 beschriebenen Dualit¨
at von Datenintegration
und funktionaler Integration kann auf der Basis der OMA auch Datenintegration hergestellt
werden. Zus¨
atzlich k¨
onnen unter Nutzung von Implementierungen erg¨
anzender Standards weitere Integrationsanforderungen erf¨
ullt werden. Ein Beispiel ist die Resource Access Decision
Facility, die f¨
ur die Realisierung von Zugriffsintegration angewendet werden kann.
4.2.4 Das Healthcare Information Framework
Ein Rahmenwerk, das f¨
ur den Anwendungsbereich der Informationsverarbeitung im Gesundheitswesen entwickelt wurde, ist das Healthcare Information Framework (HIF, Standard EN
12443: Healthcare Information Framework ) des Europ¨
aischen Komitee f¨
ur Normung (Comit´e
Europ´een de Normalisation, CEN).
¨
Das HIF ist ein Architektur-Referenzmodell. Ahnlich
dem TOGAF TRM (siehe Abschnitt
4.2.5) sieht das HIF eine Unterscheidung dreier Ebenen bei der Betrachtung von Informationssystemarchitekturen vor (Abbildung 4.6). Die Ebenen werden folgendermaßen voneinander
abgegrenzt (¨
ubersetzt aus [CEN TC251 1997], S. 10):
(Die) Gesundheitswesen-Anwendungssystemebene modelliert die Datenfl¨
usse und Funktionalit¨
aten, die ben¨
otigt
werden, um Prozesse im Gesundheitswesen zu unterst¨
utzen.
(Die) Gesundheitswesen-Middlewareebene modelliert gemeinsam genutzte Dienste, die ben¨
otigt werden, um die
Anwendungssystemebene zu unterst¨
utzen.
(Die) Gesundheitswesen-Daten¨
ubermittelungsebene modelliert die technologische Infrastruktur, die der Middlewareebene Dienste zur Verf¨
ugung stellt.
Spezielle Standards auf der Basis des HIF
Das CEN sieht f¨
ur jede der Ebenen des HIF spezielle Standards vor. Bisher existiert mit
der Healthcare Information Systems Architecture (HISA), Teil 1 (CEN-Standard EN 12967-1:
Healthcare Information Systems Architecture Part 1: Healthcare Middleware Layer ) nur f¨
ur die
Middlewareebene eine ausf¨
uhrliche Spezifikation ([CEN TC251 1997]).
In der HISA werden zwei Dienstklassen unterschieden:
– gemeinsame Dienste des Gesundheitswesens (Healthcare Common Services) und
– allgemeine gemeinsame Dienste (Generic Common Services).
Die gemeinsamen Dienste des Gesundheitswesens k¨
onnen mit den anwendungsbereichsspezifischen Diensten der OMA f¨
ur den Anwendungsbereich des Gesundheitswesens verglichen werden, die allgemeinen gemeinsamen Dienste mit den gemeinsamen Diensten der OMA.
46
4.2 Technische Rahmenwerke f¨
ur Informationssystemarchitekturen
Abbildung 4.6: Die Schichten der Architektur von Informationssystemen im Gesundheitswesen (Quelle: [CEN TC251
1997], Abbildung 1)
Zentraler Inhalt des Standards sind informationale und funktionale Spezifikationen4 von
sechs Dienstkategorien der gemeinsamen Dienste des Gesundheitswesens ([CEN TC251 1997],
S. 13):
– Dienste zum Gegenstand der Gesundheitsversorgung (Subject of Care Healthcare Common Services),
– Dienste zu Gesundheits-Charakteristika (Health Characteristic Healthcare Common Services),
– Dienste zu Aktivit¨
aten (Activity Healthcare Common Services),
– Dienste zu Ressourcen (Resource Healthcare Common Services),
– Dienste zur Autorisierung (Authorisation Healthcare Common Services) und
– Dienste zu Begriffen (Concept Healthcare Common Services).
Einige Bezeichnungen der Dienstkategorien lassen nicht unmittelbar erkennen, f¨
ur die Verwaltung welcher Informationen sie spezifiziert wurden: Gegenstand der Versorgung sind Patienten;
Gesundheits-Charakteristika sind Informationen zum Gesundheitszustand, z. B. Vitalwerte und
Befunde; Aktivit¨
aten sind hautps¨
achlich Untersuchungen und Behandlungen; Ressourcen sind
z. B. Materialien oder Medikamente. Dienste zur Autorisierung verwalten Benutzerkennungen
und Zugriffsrechte; Dienste zu Begriffen stellen beispielsweise als Terminologieserver Begriffssysteme zur Verf¨
ugung.
F¨
ur jede Dienstgruppe enth¨
alt die HISA ein Informationsmodell der verwalteten Informationen. Sie enth¨alt weiterhin eine f¨
ur alle Dienstkategorien gleiche funktionale Spezifikation
(Abbildung 4.7). Die Informationsmodelle k¨
onnen als Informations-Referenzmodelle verwendet
werden. Die funktionale Spezifikation kann als funktionale Referenz-Spezifikation f¨
ur Dienste
in Informationssystemen im Gesundheitswesen verwendet werden.
4
Die informationale Spezifikation ist die Spezifikation der zu verarbeitenden Informationen; die funktionale
Spezifikation ist die Spezifikation der bereitzustellenden Funktionalit¨
at.
47
4 Standards f¨
ur Informationssystemarchitekturen
a)
b)
Abbildung 4.7: Informationsmodell f¨
ur die Subject of Care Healthcare Common Services (a) und funktionale Spezifikation (b) (Quelle: [CEN TC251 1997], S. 15)
Integrationsanforderungen und das HIF
Der einzige bisher zum HIF ver¨offentlichte spezielle Standard, die HISA, verdeutlicht die Fokussierung der HIF-Entwicklung auf dienstbasierte Architekturen. Damit legen das HIF und
die HISA, wie auch die OMA und die zugeh¨
origen Dienstspezifikationen, Grundlagen f¨
ur funktionale Integration.
Im Gegensatz zur OMA existieren zum HIF keine Spezifikationen zur Vermittlung von
Dienstanforderungen. Es wird also keine Integrationstechnik im engeren Sinne beschrieben. Die
48
4.2 Technische Rahmenwerke f¨
ur Informationssystemarchitekturen
in der HISA spezifizierten Dienstgruppen beschreiben Informationen und zugeh¨
orige Funktionalit¨
at f¨
ur die Anwendung im Gesundheitswesen. Implementierungen der Dienste zur Autorisierung k¨
onnen zur Herstellnung von Zugriffsintegration beitragen, Implementierungen der
Dienste zu Begriffen k¨
onnen zur Herstellung von semantischer Integration beitragen.
4.2.5 The Open Group Architectural Framework, Version 7
The Open Group Architectural Framework (TOGAF) wurde von der Open Group5 auf der
Basis des Technical Architecture Framework for Information Management (TAFIM) des USamerikanischen Verteidigungsministeriums erstellt (Abbildung 4.8; [DoD DISA 1996], [The
Open Group 2001]). Hier wird zun¨
achst die Version 7 vorgestellt, die technische Aspekte
in den Vordergrund stellt. In Abschnitt 4.4.4 wird die Version 8 (genauer: 8.1) vorgestellt, die
zus¨
atzlich technikunabh¨
angige unternehmensbezogene Aspekte ber¨
ucksichtigt6 . Seine zentralen
Inhalte sind
– die TOGAF Architecture Development Method (TOGAF ADM) und
– die TOGAF Foundation Architecture.
5
6
Die (The) Open Group ist eine internationale Organisation, die die Open Software Foundation (OSF) und
die X/Open-Organisation zusammenfasst.
Beide TOGAF-Versionen wurden zur Zeit der Erstellung dieser Arbeit parallel von der Open Group publiziert. Sofern in bestimmten Projekten unternehmensbezogene Aspekte ausgeblendet werden k¨
onnen, kann die
Anwendung der Version 7 anstelle der Version 8 effizienter sein.
Abk¨
urzungen:
C4ISR
Command, Control, Communications, Computers, Intelligence,
Surveillance, and Reconnaissance
(US Department of Defense)
DoD TRM
Department of Defense Technical
Reference Model
DoD AF
Department of Defense Architecture Framework
EAP
Enterprise Architecture Planning
(S. H. Spewak)
FEAF
Federal Enterprise Architecture
Framework
(US Federal CIO
Council)
JTA
Joint Technical Architecture (US
Department of Defense)
POSIX
ISO/IEC TR 14252:1996: Guide
to the POSIX Open System Environment (ISO/IEC)
TAFIM
Technical Architecture Framework for Information Management (US Department of Defense)
TEAF
Treasury Enterprise Architecture
Framework (US Department of
the Treasury)
TISAF
Treasury Information System Architecture Framework (US Department of the Treasury)
TOGAF
The Open Group Architectural
Framework (The Open Group)
Zachman
Framework for Information Systems Architecture (J. A. Zachman)
Abbildung 4.8: TOGAF und seine Beziehungen zu anderen US-amerikanischen Rahmenwerken (Quelle: unbekannt)
49
4 Standards f¨
ur Informationssystemarchitekturen
Die TOGAF Architecture Development Method
Die TOGAF Architecture Development Method (TOGAF ADM) ist ein Vorgehens-Referenzmodell (siehe K¨
asten Grundbegriffe (4)“ und Grundbegriffe (5)“). Sie beschreibt Phasen f¨
ur
”
”
das Vorgehen zur Entwicklung und Weiterentwicklung von Informationssystemarchitekturen.
Die Phasen und ihre Ziele sind (¨
ubersetzt aus [The Open Group 2001], Part II):
Phase A: Einleitung und Rahmenbedingungen
Ziel: Ziel dieser Phase ist es, basierend auf den Grunds¨
atzen, Unternehmenszielen und strategischen Faktoren des
Unternehmens die relevanten Unternehmensanforderungen, die f¨
ur diese Architekturentwicklung gelten, und eine
Vision der Architektur, die eine Antwort auf die Anforderungen zeigt, zu definieren.
Phase B: Basisbeschreibung
Ziel: Ziel dieser Phase ist es, auf hoher Ebene eine Beschreibung der Charakteristika des vorhandenen Systems zu
erstellen. Das ist notwendig, da die Beschreibung den Ausgangspunkt der Architekturentwicklung dokumentiert
und Interoperabilit¨
atsprobleme aufz¨
ahlt, die die endg¨
ultige Architektur ber¨
ucksichtigen muss.
Phase C: Zielarchitektur
Ziel: Ziel dieser Phase ist es, die Zielarchitektur zu ermitteln, die die Grundlage der folgenden Implementierungsarbeiten bildet.
Phase D: M¨
oglichkeiten und L¨
osungen
¨
¨
Ziel: Diese Phase ermittelt die Kenngr¨
oßen der vorzunehmenden Anderungen,
die Hauptphasen des Anderungsprozesses und die Projekte auf h¨
ochster Ebene, die durchgef¨
uhrt werden m¨
ussen, um vom Ist- zum Zielzustand zu
gelangen. Sie bildet die Basis des Implementierungsplans, der f¨
ur den Wechsel zur Zielarchitektur notwendig ist.
Phase E: Migrationsplanung
Ziel: Ziel dieser Phase ist es, die verschiedenen Implementierungsprojekte nach ihrer Priorit¨
at zu ordnen. Zu den
Aktivit¨
aten geh¨
oren die Bewertung der Abh¨
angigkeiten, Kosten und Nutzen der verschiedenen Migrationsprojekte.
Die nach Priorit¨
at geordnete Projektliste ist weitere Grundlage f¨
ur den Implementierungsplan.
Phase F: Implementierung
Ziel: Ziel dieser Phase ist es, Empfehlungen f¨
ur jedes Implementierungsprojekt zu formulieren und eine Architekturvereinbarung zu erstellen, die die Systemimplementierung und -bereitstellung regelt. Dann wird in dieser Phase
das System implementiert und bereitgestellt.
Phase G: Architekturwartung
Ziel: Ziel dieser Phase ist es, ein Wartungsverfahren f¨
ur die neue Basis, die mit Beendigung der Implementie¨
rung erreicht wird, festzulegen. Dieses Verfahren wird u
ur eine kontinuierliche Uberwachung
von –
¨blicherweise f¨
¨
unter anderem – neuen technologischen Entwicklungen und Anderungen
im Unternehmensumfeld sowie f¨
ur die
Bestimmung, ob ein neuer Architekturentwicklungszyklus zu initiieren ist, sorgen.
Jede Phase der TOGAF ADM ist unterteilt in Arbeitsschritte. Phase C besteht beispielsweise aus acht Schritten (¨
ubersetzt aus [The Open Group 2001], Part II, Phase C, siehe
Abbildung 4.9):
1. Repr¨
asentation der Basisbeschreibung unter Anwendung der TOGAF Foundation Architecture, um einen gemeinsamen Ausgangspunkt anzugeben,
2. Pr¨
ufung verschiedener Standpunkte bez¨
uglich der Architektur, um sicherzustellen, dass die Anforderungen aller
Interessengruppen an das geforderte System ber¨
ucksichtigt werden,
3. Auswahl eines Architekturmodells auf hoher Ebene,
4. Festlegung einer Menge von Kriterien f¨
ur die Dienstauswahl,
5. Auswahl der ben¨
otigten Dienste,
6. Pr¨
ufung, ob die Unternehmensziele eingehalten werden,
7. detaillierte Definition der Architektur und
8. Durchf¨
uhrung einer Diskrepanzanalyse, um jede fehlende Funktionalit¨
at zu ermitteln.
50
4.2 Technische Rahmenwerke f¨
ur Informationssystemarchitekturen
Abbildung 4.9: Die Phasen der TOGAF Architecture Development Method und die Schritte der Phase C (Quelle: [The
Open Group 2001], Part II, Introduction, Figure 2)
Das TOGAF Technical Reference Model
Die bereits vorgestellte TOGAF ADM ist, wie oben beschrieben, ein Vorgehens-Referenzmodell.
TOGAF enth¨
alt weiterhin ein Architektur-Referenzmodell,
– das TOGAF Technical Reference Model (TOGAF TRM).
Es wird erg¨
anzt um Listen von Standards f¨
ur die im TOGAF TRM angegebenen Dienstkategorien:
– die TOGAF Standards Information Base (TOGAF SIB).
¨
TOGAF TRM und TOGAF SIB werden unter der Uberschrift
TOGAF Foundation Architecture zusammengefasst ([The Open Group 2001], Part III). Die oben beschriebene TOGAF
¨
ADM kann als Vorgehens-Referenzmodell f¨
ur die Uberf¨
uhrung des TOGAF TRM in ein spezifisches Architekturmodell betrachtet werden.
Das TOGAF TRM sieht f¨
ur die Informationssystembeschreibung eine Unterteilung in drei
Einheiten vor (Abbildung 4.10):
– die Anwendungssysteme, unterteilt in gesch¨
aftsspezifische und infrastrukturelle Anwendungssysteme,
– die Anwendungsplattform7 mit verschiedenen Dienstkategorien und
– die Kommunikationsinfrastruktur.
Zu den drei Einheiten, haupts¨
achlich zu den Dienstkategorien der Anwendungsplattform,
werden Erkl¨
arungstexte, jedoch keine formalen Beschreibungen, angegeben.
Die Unterteilung in die drei Einheiten ¨
ahnelt den Ebenen des Healthcare Information Framework; die Dienstkategorien ¨
ahneln den Dienstkategorien der Healthcare Information Systems
Architecture (siehe Abschnitt 4.2.4).
7
Vgl. Plattformbegriff in Abschnitt 4.2.3.
51
4 Standards f¨
ur Informationssystemarchitekturen
a)
b)
Abbildung 4.10: Einfache (a) und detailliertere (b) Grafik zum TOGAF TRM (Quellen: [The Open Group 2001], Part
III, High-level Breakdown, Figure 1 und Part III, TRM in Detail, Figure 1)
Die TOGAF Standards Information Base – Standards f¨
ur die Anwendung des TOGAF
TRM
Im Gegensatz zu den bisher vorgestellten Rahmenwerken ist TOGAF selbst nicht Grundlage
f¨
ur die Entwicklung spezieller Standards f¨
ur Integrationstechniken.
Von der Open Group wird f¨
ur die Anwendung des TOGAF TRM eine sehr umfassende
Sammlung von Standards, die TOGAF Standards Information Base. Sie enth¨
alt Listen von
und Verweise auf Standards f¨
ur Dienste der einzelnen im TOGAF TRM genannten Dienstkategorien. Dabei werden nicht nur Dienstspezifikationen im Sinne der OMA-basierten Dienste
angegeben, sondern auch Protokolle f¨
ur den Datenaustausch, Dateiformatspezifikationen und
viele weitere Standards. Die Standarddokumente selbst sind jedoch nicht unmittelbar in der
SIB enthalten. Beispiele f¨
ur angegebene Standards sind
– HTML 4.0 Reference Specification,
– ISO/IEC 10918: Information technology – Digital compression and coding of continuoustone still images (JPEG-Spezifikation) oder
– X/Open C525: Protocols for X/Open Interworking: XNFS - Version 3.
Die ersten beiden geh¨
oren zur Kategorie der Datenaustauschdienste (data interchange services),
X/Open C525 geh¨
ort zur Kategorie der Netzwerkdienste (network services).
Die TOGAF SIB enth¨
alt u. a. auch die in Abschnitt 4.2.1 genannten Standards bzw. Protokolle IEEE 802.X, IP, TCP, ASCII, TIFF, MPEG und FTP sowie die in Abschnitt 4.2.3
beschriebene CORBA.
52
4.3 Weitere Standards f¨
ur Integrationstechniken
Integrationsanforderungen und TOGAF
TOGAF wurde entwickelt, um Projekte zur Entwicklung bzw. Weiterentwicklung von Architekturen zu unterst¨
utzen. Damit kann TOGAF indirekt u
utzung von Integrati¨ ber die Unterst¨
onsprojekten, die immer auch die Architektur betreffen, zur Erf¨
ullung von Integrationsanforderungen beitragen.
Die in der TOGAF SIB enthaltenen Standards k¨
onnen prinzipiell zur Herstellung aller Integrationsanforderungen beitragen.
4.3 Weitere Standards f¨
ur Integrationstechniken
Neben den im vorhergehenden Abschnitt vorgestellten Standards f¨
ur Integrationstechniken
und zugrunde liegenden Rahmenwerken existieren viele weitere, die nicht unmittelbar mit den
vorgestellten Rahmenwerken in Beziehung stehen. Sie k¨
onnen jedoch f¨
ur die Erf¨
ullung mancher
der in Kapitel 2 beschriebenen Integrationsanforderungen genutzt werden. Einige Beispiele
werden im Folgenden kurz vorgestellt.
Das Distributed Component Object Model
Das Distributed Component Object Model (DCOM) ist ein von der Firma Microsoft entwickelter Ansatz f¨
ur die Beschreibung und Implementierung verteilter Komponenten, die Dienste
bereitstellen. Er basiert auf dem Component Object Model (COM). Das COM und seine Erweiterung DCOM sind vergleichbar mit der CORBA ([Emmerich 2003], S. 133-148). Sie sind,
ahnlich der CORBA, f¨
ur die Realisierung von funktionaler Integration geeignet.
¨
Terminologieserver
Terminologieserver stellen Begriffsverzeichnisse zur Verf¨
ugung. Neben der einfachen Bereitstellung der Verzeichnisse bieten sie i. d. R. umfangreiche Funktionen zur Suche von Begriffen oder
zur Abbildung von Begriffssystemen aufeinander an. Oft enthalten sie Verweise auf weiterf¨
uhrende Literatur zu den Begriffen ([Ingenerf and Diedrich 1997]). Terminologieserver sind
f¨
ur die Realisierung von semantischer Integration geeignet.
HL7 Context Management Standard
Die Clinical Context Object Workgroup (CCOW), die zur HL7-Organisation geh¨
ort, hat eine
Standard-Reihe f¨
ur Kontextintegration ver¨offentlicht.
Der Kern“-Standard Health Level Seven Standard Context Management Specification,
”
”
Technology- and Subject-Independent Component Architecture“ sieht vor, dass Anwendungssysteme, die hinsichtlich eines bestimmten Kontextes synchronisiert werden m¨
ussen, u
¨ ber eine zentrale Komponente, den Kontextmanager, koordiniert werden. Der Standard beschreibt
die notwendigen Schnittstellen des Kontextmanagers und der beteiligten Anwendungssysteme
([CCOW 2000c]).
Speziell f¨
ur den Patientenkontext und den Benutzerkontext wurden erg¨
anzende Standards
ver¨
offentlicht, die die Spezifikationen der speziellen Kontextdaten beinhalten ([CCOW 2000a],
53
4 Standards f¨
ur Informationssystemarchitekturen
[CCOW 2000b]). Zur Standard-Reihe geh¨
oren außerdem Standards zur Umsetzung der Kontextsynchronisierung auf der Basis bestimmter Techniken.
Standards f¨
ur Pr¨
asentationsintegration
F¨
ur die Herstellung von Pr¨
asentationsintegration wurden mehrere Standards zur Gestaltung
von Benutzungsschnittstellen entworfen. Sie enthalten Vorschriften und Richtlinien f¨
ur die Gestaltung von Bildschirmelementen wie Men¨
us, Tabellen oder Steuerelemente f¨
ur Dialogfenster.
Beispiele sind Common User Application (CUA) von IBM ([Berry and Reeves 1992]),
Motif ([X/Open 1995]), die Apple Human Interface Guidelines ([Apple Computer Inc.
1987]) und die Grunds¨
atze ergonomischer Dialoggestaltung f¨
ur Bildschirmarbeitspl¨
atze (Standard DIN 66234, Teil 8; vgl. auch Standard ISO 9241-10) des Deutschen Institutes f¨
ur Normung
(DIN) ([DIN 1988]).
4.4 Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen
Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen enthalten, wie die
im vorhergehenden Abschnitt vorgestellten technischen Rahmenwerke, Empfehlungen oder Anleitungen f¨
ur ein systematisches Management von Informationssystemen. Sie schließen unternehmensorientierte Managementmethoden und -werkzeuge, z. B. f¨
ur die Gesch¨
aftsprozessmodellierung, in die Architekturbetrachtung ein. Manche von ihnen sind aus technischen Rahmenwerken f¨
ur Informationssystemarchitekturen entstanden und deshalb durch diese gepr¨
agt
(z. B. TOGAF, siehe Abschnitte 4.2.5 und 4.4.4).
Auch unternehmensbezogene Rahmenwerke stellen Vorgehens-Referenzmodelle zur Verf¨
ugung oder geben durch Unterscheidung verschiedener Sichten Unterst¨
utzung bei der Entwicklung oder Weiterentwicklung von Informationssystemarchitekturen (vgl. Abschnitt 4.2).
Spezielle Standards f¨
ur Integrationstechniken und unternehmensbezogene Rahmenwerke
Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen bilden i. d. R. nicht
die Grundlage f¨
ur die Entwicklung spezieller Standards f¨
ur bestimmte Integrationstechniken.
Sie wurden entwickelt, um die Durchf¨
uhrung architekturbezogener Projekte unter Ber¨
ucksichtigung der Ziele, der Gesch¨
aftsprozesse und weiterer Spezifika des betrachteten Unternehmens zu
unterst¨
utzen. In den folgenden Abschnitten sind daher, im Gegensatz zu den vorhergehenden,
keine Unterabschnitte zu speziellen Standards f¨
ur Integrationstechniken enthalten.
Eine Ausnahme ist der in Abschnitt 4.4.3 beschriebene Ansatz Enterprise Application Integration (EAI). Geleitet durch die EAI-Bestrebungen wurde die Entwicklung verschiedener Integrationstechniken vorangetrieben und die Anwendung existierender Techniken gef¨
ordert. Der
Abschnitt zu EAI enth¨
alt also kurze Unterabschnitte zur EAI-Technologie und zu ArchitekturReferenzmodellen f¨
ur EAI.
Integrationsanforderungen und unternehmensbezogene Rahmenwerke
Mit der genannten Unabh¨
angigkeit unternehmensbezogener Rahmenwerke von speziellen Integrationstechniken ist auch eine Unabh¨
angigkeit von einzelnen Integrationsanforderungen oder
54
4.4 Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen
Abbildung 4.11: Das Zachman-Rahmenwerk f¨
ur Informationssystemarchitektur (Quelle: [Zachman 1999])
Anforderungskategorien verbunden. Alle Projekte, die die Integration und damit auch die
Architektur betreffen, sollten durch unternehmensbezogene Rahmenwerke unterst¨
utzt werden
k¨
onnen. In den folgenden Abschnitten sind daher, im Gegensatz zu den vorhergehenden, keine
Unterabschnitte zu Integrationsanforderungen enthalten.
4.4.1 Das Zachman-Rahmenwerk
Das Framework for Information Systems Architecture von J. A. Zachman (Zachman-Rahmenwerk) ist eines der ersten unternehmensbezogenen Rahmenwerke f¨
ur Informationssystemarchi-
55
4 Standards f¨
ur Informationssystemarchitekturen
tekturen. Es ist wesentliche Grundlage f¨
ur die Entwicklung einer Reihe von US-amerikanischen
Rahmenwerken (Abbildung 4.8).
Im Gegensatz zum TOGAF (siehe Abschnitte 4.2.5 und 4.4.4) steht im Zachman-Rahmenwerk nicht ein Vorgehens-Referenzmodell, sondern die Unterscheidung verschiedener Sichtweisen auf Informationssysteme bzw. ihre Architektur im Mittelpunkt. Im Zachman-Rahmenwerk
werden dazu f¨
unf Sichtweisen unterschieden (¨
ubersetzt aus [Zachman 1987]):
–
–
–
–
–
die Anwendungsbereichsbeschreibung (Rahmensichtweise8 ),
das Gesch¨
aftsmodell / Unternehmensmodell (Sichtweise des Eigent¨
umers),
das Informationssystemmodell (Konstrukteurssichtweise),
das technische Modell (Sichtweise des Erbauers) und
die detaillierte (technische) Beschreibung (kontextlose Sichtweise).
Diese Sichtweisen werden jeweils in
– eine Datenbeschreibung,
– eine Prozessbeschreibung und
– eine Netzwerkbeschreibung
aufgeteilt (Abbildung 4.11). Damit ergibt sich eine Matrix, deren Zellen f¨
ur unterschiedliche
Architekturbetrachtungen stehen.
Jeder dieser Architekturbetrachtungen kann ein Vorrat an Methoden und Werkzeugen, insbesondere f¨
ur die Modellierung, zugeordnet werden. Beispielsweise sind f¨
ur die Prozessbeschreibung innerhalb des Unternehmensmodells Methoden und Werkzeuge der Gesch¨
aftsprozessmodellierung geeignet. F¨
ur die Datenbeschreibung innerhalb des technischen Modells k¨
onnen
z. B. Datenbankschemabeschreibungen verwendet werden. Diese Zuordnung wird im ZachmanRahmenwerk jedoch nicht ausdr¨
ucklich vorgenommen.
4.4.2 Die Architektur integrierter Informationssysteme
Die Architektur integrierter Informationssysteme (ARIS) ist der vermutlich bekannteste deutsche Ansatz zu Informationssystemarchitekturen ([Scheer 1998b], [Scheer 1998a]). Sie ist
in der universit¨
aren Forschung entstanden und hat durch erfolgreichen Transfer in die Wirtschaft große Verbreitung gefunden. Ihre Anwendung in mehreren großen Unternehmen hat die
Verbreitung gef¨
ordert.
Im ARIS-Ansatz werden f¨
unf Sichten9 auf Informationssysteme unterschieden (Abbildung
4.12):
–
–
–
–
–
die
die
die
die
die
Organisationssicht,
Steuerungssicht,
Datensicht,
Funktionssicht und
Leistungssicht.
Jeder der Sichten werden drei Ebenen zugeordnet:
8
9
In [Zachman 1987] wird die Bezeichnung view verwendet. Hier wird davon ausgegangen, dass damit der
Begriff Sichtweise, wie er bisher in diesem Kapitel verwendet wurde, gemeint ist.
Die in der ARIS verwendete Bezeichnung Sicht entspricht dem Begriff Sichtweise, wie er bisher in diesem
Kapitel verwendet wurde.
56
4.4 Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen
Abbildung 4.12: Das ARIS-Haus (Quelle: [Scheer 1998b], S. 46, Abbildung 20)
– das Fachkonzept,
– das DV-Konzept und
– die Implementierung.
Jedem Sicht-Ebene-Paar k¨
onnen Methoden und Werkzeuge f¨
ur seine Bearbeitung zugeordnet
werden. [Scheer 1998b] und [Scheer 1998a] enthalten entsprechende Vorgaben und Empfehlungen (siehe Kasten Beispiele f¨
ur Methoden zur Datensicht und zur Steuerungssicht der
”
ARIS“).
Die in den Fachkonzepten und DV-Konzepten zul¨
assigen Begriffe und deren Beziehungen
Abbildung 4.13: Metamodell der Fachkonzeptebene der Funktionssicht (Ausschnitt, Quelle: [Scheer 1998a], S. 38,
Abbildung 33)
57
4 Standards f¨
ur Informationssystemarchitekturen
Kasten 4.5: Beispiele f¨
ur Methoden zur Datensicht und zur Steuerungssicht
der ARIS
Hinweis: Die Beispiele k¨
onnen die Komplexit¨
at des ARIS-Ansatzes nicht vollst¨
andig wiedergeben.
Datensicht
Steuerungssicht
Bei der Erstellung des Fachkonzeptes werden Informationsmodelle (auch: semantische Datenmodelle)
erstellt, z. B. auf der Basis des Entity-RelationshipModells:
Bei der Erstellung des Fachkonzeptes werden u. a.
ereignisgesteuerte Prozessketten (EPK) verwendet:
(Quelle: [IDS Scheer AG 2004])
Weiterhin werden u. a.
(Quelle: [IDS Scheer AG 2004])
Bei der Erstellung des DV-Konzeptes werden implementierungsabh¨
angige logische Datenmodelle, z. B.
relationale Datenmodelle, verwendet.
Kunde (Kunden Nr., Name, Adresse, . . . )
Organisationseinheit (OE Nr., Name, . . . )
Dabei ist, sofern zutreffend, auch die Einhaltung von
Normalformen zu beachten.
Die logischen Datenmodelle werden in die Datenbeschreibungssprache (Data Description Language
(DDL), auch: Datendefinitionssprache (Data Definition Language)) der verwendeten Datenbanksysteme
u
uhrt, z. B. in einen SQL-Dialekt.
¨berf¨
CREATE TABLE kunden (
kundennr DECIMAL(10) PRIMARY KEY,
...
);
Zum DV-Konzept der Datensicht geh¨
ort auch das Definieren von Datenbanktriggern, die die Datenintegrit¨
at sichern.
Bei der Implementierung des DV-Konzeptes werden interne Datenbankschemata angelegt, bei denen, im Unterschied zu den Datenbankschemata des
DV-Konzeptes, u. a. Optimierungen f¨
ur schnelleren
Zugriff vorgenommen werden. Dabei wird die zum
Datenbanksystem geh¨
orende Datenspeicherbeschreibungssprache (Data Storage Description Language
DSDL) verwendet.
(vgl. [Scheer 1998a])
58
– Funktions-Organisationszuordnungsdiagramme,
– Klassendiagramme, basierend auf der objektorientierten Analyse (OOA), und
– Anwendungsfalldiagramme (Use Case Diagrams)
verwendet. Die Verwendung der verschiedenen Methoden f¨
ur die Steuerungssicht ergibt sich aus den
verschiedenen Verkn¨
upfungen zwischen den Sichten.
Im DV-Konzept werden die im Fachkonzept angegebenen Steuerungsvorgaben implementierungsabh¨
angig definiert. Dazu geh¨
oren u. a.
– Verfeinerungen des objektorientierten Entwurfs
des Fachkonzeptes und Erg¨
anzung um Zustands-, Sequenz- und Aktivit¨
atendiagramme,
[Anmeldedaten
unvollständig]
ablehnen
Kundenanmeldung
abgelehnt
Kundenanmeldung
eingetroffen
annehmen
[Anmeldedaten
vollständig]
Kundenanmeldung
angenommen
– Zuordnungen von Datenbankschemata aus der
Datensicht zu Modulen der Funktionssicht
und
– Definitionen von Datenbanktransaktionen und
Datenbanktriggern.
Bei der Implementierung wird das DV-Konzept mit
Hilfe von Programmiersprachen und den von den Datenbankmanagementsystemen bereitgestellten Funktionen in ausf¨
uhrbare Anwendungssysteme u
uhrt.
¨berf¨
4.4 Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen
Abbildung 4.14: Das ARIS-Phasenmodell (Quelle: [Scheer 1998b], S. 39, Abbildung 16)
werden durch miteinander verkn¨
upfte Metamodelle vorgeschrieben. Dadurch werden die Arbeiten zum Architekturentwurf, die zu den einzelnen Sicht-Ebene-Paaren geh¨
oren, aufeinander
abgestimmt. Die Metamodelle wurden als Klassendiagramme mit der Unified Modeling Language (UML) erstellt. Das durch Verkn¨
upfung der einzelnen Metamodelle entstehende ARISMetamodell wird auch ARIS-Informationsmodell genannt (Abbildung 4.13).
Die Sichten und Ebenen des ARIS-Ansatzes sind eingebettet in einen Gesch¨
aftsprozessrahmen. Die Optimierung von Gesch¨
aftsprozessen ist danach Hauptziel jeder Entwicklung bzw.
Weiterentwicklung von Informationssystemen (vgl. Abschnitt 5.2). Prozessmodelle sind wich¨
tiger Ausgangspunkt f¨
ur den Architekturentwurf. Gleichzeitig beeinflusst jede Anderung
der
Architektur die Gesch¨
aftsprozesse. Die Zusammenh¨
ange zwischen
–
–
–
–
Prozessgestaltung,
Prozessplanung und -steuerung,
Workflowsteuerung und
Anwendungssystemen
sind in einem Phasenmodell festgehalten (Abbildung 4.14).
59
4 Standards f¨
ur Informationssystemarchitekturen
4.4.3 Enterprise Application Integration
Unter dem Titel Enterprise Application Integration (EAI) wurde in den letzten Jahren ein
umfassender Integrationsansatz propagiert und diskutiert ([Hasselbring 2000], [Linthicum
2000b]). Es existiert kein offizieller Standard oder allgemein anerkanntes Rahmenwerk, das EAI
und die zugeh¨
origen Methoden definiert und gegen¨
uber anderen Architektur- oder Integrationsans¨
atzen abgrenzt.
Ausgangspunkt der EAI-Bestrebungen ist die in vielen Unternehmen vorhandene Vielfalt
an Werkzeugen zur Informationsverarbeitung: Unterschiedliche Organisationseinheiten eines
Unternehmens, m¨
oglicherweise auch einzelne Mitarbeiter innerhalb einer Organisationseinheit,
nutzen unterschiedliche Werkzeuge bei der Erf¨
ullung unterschiedlicher oder eventuell sogar
derselben Aufgaben. Dieser Sachverhalt wird hier nach [Hasselbring 2000] als vertikale Fragmentierung eines Informationssystems bezeichnet.
Die Gew¨
ahrleistung einer angemessenen Zusammenarbeit der Mitarbeiter bzw. der Einrichtungen, die f¨
ur das Erreichen der Unternehmensziele notwendig ist, stellt oft eine große Herausforderung f¨
ur das Unternehmen dar. Im Zentrum der EAI-Bestrebungen steht die Integration
vorhandener Anwendungssysteme, die auf einen bestimmten Anwendungsbereich zugeschnitten
sind, jedoch nicht oder kaum auf die Integration mit anderen Anwendungssystemen vorbereitet sind. Diese Anwendungssysteme werden auch als Altsysteme (legacy systems) bezeichnet
[Hasselbring 2000].
EAI-Ebenen
¨
In der EAI-Literatur spiegelt sich u. a. die Idee der Uberwindung
vertikaler Fragmentierung
durch horizontale Integration auf verschiedenen Ebenen wider. In [Hasselbring 2000] wird
die Unterscheidung von verschiedenen Integrationsebenen zun¨
achst zur Abgrenzung von EAI
gegen¨
uber anderen Integrationstypen genutzt (Abbildung 4.15). In der EAI-Literatur wird
dieser Ansatz durch Unterscheidung verschiedener EAI-Typen bzw. -Ebenen weitergef¨
uhrt bzw.
erg¨
anzt.
Unterscheidungen mehrerer Ebenen, auf denen Integration hergestellt werden kann, k¨
onnen als Rahmenwerke betrachtet werden, die Orientierung in Integrationsprojekten geben.
Abbildung 4.16a zeigt die Einordnung von EAI als eine von drei Integrationsebenen, die Abbildungen 4.16b und c zeigen die in [Linthicum 2000b] und [Longo 2001] beschriebenen
Abbildung 4.15: Vertikale Fragmentierung von Informationssystemen und horizontale Integration (Quelle: [Hasselbring
2000], S. 34-35, Figure 1 und Figure 2)
60
4.4 Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen
a)
Inter-Organizational
Processes
Enterprise Application
Integration
Middleware Integration
b)
c)
Business-to-Customer
Integration
User Interface Level EAI
Method Level EAI
Application Interface
Level EAI
Business-to-Business
Integration
Application-to-Application
Integration
Component-Based
Applications Development
Data Level EAI
Abbildung 4.16: Unterscheidung von Integrationsebenen in [Hasselbring 2000] (a) sowie von EAI-Ebenen in [Linthicum
2000b] (b) und in [Longo 2001] (c)
EAI-Ebenen10 . In [Linthicum 2000b] werden die EAI-Ebenen folgendermaßen beschrieben
(auszugsweise u
¨ bersetzt aus [Linthicum 2000b], S. 18-2011 ):
Daten-EAI ist der Prozess, inkl. der Techniken und Technologie, des Bewegens von Daten zwischen Datenspeichern.
Das kann als das Extrahieren von Informationen aus einer Datenbank, eventuell das Verarbeiten der Informationen
soweit erforderlich und das Aktualisieren der Informationen in einer anderen Datenbank beschrieben werden.
Anwendungssystemschnittstellen-EAI bezieht sich auf die Nutzung von Schnittstellen, die von kundenspezifischen
oder handels¨
ublichen Anwendungssystemen bereitgestellt werden. Entwickler nutzen diese Schnittstellen, um sowohl auf Gesch¨
aftsprozesse als auch auf einfache Informationen zuzugreifen.
Methoden-EAI ist die gemeinsame Nutzung der Gesch¨
aftslogik, die innerhalb eines Unternehmens vorhanden ist.
Beispielsweise k¨
onnte die Methode12 zur Aktualisierung einer Kundenakte von mehreren Anwendungssystemen
aufgerufen werden, und Anwendungssysteme k¨
onnten ihre Methoden gegenseitig aufrufen, ohne dass jede Methode
in jedem einzelnen Anwendungssystem neu geschrieben werden muss.
Benutzungsschnittstellen-EAI ist ein eher primitiver, aber trotzdem wichtiger Ansatz. Bei Anwendung dieses Szenarios k¨
onnen Architekten und Entwickler Anwendungssysteme durch Nutzung ihrer Benutzungsschnittstellen als
gemeinsamen Integrationsbezugspunkt b¨
undeln.
EAI-Technologie
Integrationstechnologien und zugeh¨
orige Integrationstechniken f¨
ullen einen großen Anteil der
EAI-Literatur aus. Sehr oft beschriebene Technologien sind
– die Technologie der nachrichtenorientierten Middleware (message-oriented middleware, MOM), wobei insbesondere Kommunikationsserver (message broker) eine bedeutende
Rolle einnehmen, ([Linthicum 2000b], S. 291-317, [Lublinsky 2002], [Bloch and Bruce 2004], [Niemann et al. 2002]),
– die Technologie des Internets mit ihren vielen unterschiedlichen, sich oft erg¨
anzenden
Techniken, z. B. dem Hypertext Transfer Protocol (HTTP) oder den Java Server Pages
(JSP), ([Juric 2002], [Lublinsky and Farrel Jr. 2001], [Bloch and Bruce 2004])
oder, eng damit verkn¨
upft,
– die Technologie der verteilten Bereitstellung von Anwendungsfunktionalit¨
at u
¨ ber Komponenten auf Anwendungsservern (application server). Bekannte Industriestandards f¨
ur
10
11
Erg¨
anzend siehe z. B. auch die Unterscheidung von B2B-Integrationstypen in [Lublinsky 2002].
Die Abk¨
urzung EAI wird hier nicht u
¨ bersetzt.
61
4 Standards f¨
ur Informationssystemarchitekturen
diese Komponenten sind Enterprise Java Beans (EJB) oder das Component Object Model (COM/COM+). F¨
ur die Kommunikation mit bzw. zwischen verteilten Objekten sind
Standards wie die CORBA (vgl. Abschnitt 4.2.3) oder das Distributed Component Object
Model (DCOM) (vgl. Abschnitt 4.3) von Bedeutung ([Linthicum 2000a]).
Im Zusammenhang mit den verschiedenen EAI-Ebenen aus [Linthicum 2000b] werden im
selben Werk auch daf¨
ur geeignete Integrationstechniken genannt. Zur Realisierung von DatenEAI sind beispielsweise Techniken zum Datenbankzugriff geeignet. Dabei m¨
ussen u. a.
– die Funktionsweise der von Datenbanksystemen bereitgestellten Schnittstellen, z. B. Open
DataBase Connectivity (ODBC) oder Java Database Connectivity (JDBC),
– die den Datenbanken zugrunde liegenden Datenmodellierungsans¨
atze, z. B. relationaler
oder objektorientierter Ansatz, und
– die auf den Datenmodellierungsans¨
atzen basierenden Datenbankschemata
ber¨
ucksichtigt werden ([Linthicum 2000b], S. 23-36, siehe auch [Lublinsky 2002]). Zur Realisierung von Methoden-EAI sind beispielsweise Techniken zum verteilten Aufruf von Methoden
geeignet. Dabei m¨
ussen u. a.
– die in den beteiligten Anwendungssystemen bereitgestellte Funktionalit¨
at und
– die zur Verf¨
ugung stehenden Vermittlungstechniken, z. B. Object Request Broker (ORB)
oder Transaction Processing Monitor (TP monitor),
ber¨
ucksichtigt werden ([Linthicum 2000b], S. 61-77).
EAI-Architektur-Referenzmodelle
In [Schmidt 2002] wird ein einfaches Architektur-Referenzmodell mit f¨
unf Ebenen f¨
ur die
Unterst¨
utzung von EAI beschrieben. Es ordnet jeder der Architekturebenen einige zur betreffenden Ebene geh¨
orende Modelle und Dienste zu (Abbildung 4.17).
Im Beitrag [Lutz 2000] werden f¨
unf Architekturmuster f¨
ur EAI vorgestellt, die zum Verst¨
andnis der vielen unterschiedlichen EAI-Ans¨
atze beitragen k¨
onnen (Abbildung 4.18). Die
ersten vier Muster haben eine zentrale Komponente, die auch den Namen des Musters bestimmt (¨
ubersetzt aus [Lutz 2000], S. 66):
1. Der Integrationsadapter (integration adapter) wandelt eine vorhandene Anwendungssystemschnittstelle in eine ben¨
otigte Schnittstelle um.
2. Der Integrationsbote (integration messenger) minimiert die Kommunikationsabh¨
angigkeiten zwischen Anwendungssystemen hinsichtlich.
3. Die Integrationsfassade (integration fa¸
cade)13 stellt eine vereinfachte Schnittstelle
zu Server-Komponenten (back-end applications) zur Verf¨
ugung, um die Abh¨
angigkeiten
zwischen Client- und Server-Komponenten zu minimieren.
4. Der Integrationsmediator (integration mediator) kapselt die Interaktionslogik von
Anwendungssystemen, um die Abh¨
angigkeiten zwischen verschiedenen Anwendungssystemen zu minimieren.
5. Das Prozessautomatisierungsmuster (process automator pattern) beschreibt
einen Architekturansatz f¨
ur die Minimierung der Abh¨
angigkeiten zwischen Prozessautomatisierungslogik und Anwendungssystemen.
13
In [Lutz 2000] wird der Buchstabe ¸c im Text, jedoch nicht in den Abbildungen verwendet.
62
4.4 Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen
Abbildung 4.17: Einfaches Architektur-Referenzmodell f¨
ur EAI (Quelle: [Schmidt 2002])
Beispiel f¨
ur Integrationsadapter sind die sogenannten H¨
ullen (Wrapper), die spezielle Anwendungssystemschnittstellen auf von anderen Komponenten besser nutzbare Schnittstellen
abbilden. Sie k¨
onnen wichtiges Hilfsmittel sein, um die anderen EAI-Architekturmuster umzusetzen.
Beispiele f¨
ur Integrationsboten sind Nachrichtenpuffersysteme oder auch Kommunikations¨
server, mit i. d. R. m¨
achtiger Funktionalit¨
at f¨
ur die Filterung, die Ubersetzung
und die Pufferung von Nachrichten.
Integrationsfassaden kommen u. a. dann zum Einsatz, wenn die von mehreren Servern bereitgestellten Schnittstellen f¨
ur den Zugriff durch Clients vereinheitlicht und zusammengefasst
werden sollen. Beispiel ist eine Komponente, u
ugbarkeit von unterschiedlichen
¨ ber die die Verf¨
Server-Komponenten abgefragt werden kann.
Integrationsmediatoren kommen u. a. dann zum Einsatz, wenn Informationen oder Funktionalit¨
aten, die wichtig f¨
ur die gemeinsame Nutzung von Anwendungssystemen sind, aus den
speziellen Anwendungssystemen herausgel¨ost werden. Beispiel ist eine Komponente, die die
Abbildung von Identifikationsnummern aus dem Nummernraum eines Anwendungssystems in
den Nummernraum anderer Anwendungssysteme vornimmt. Aus dem Gesundheitswesen kann
in diesem Zusammenhang das Konzept des Master Patient Index genannt werden.
Das Prozessautomatisierungsmuster nutzt eine spezielle Form der Integrationsfassaden, die
das Initiieren von Aktivit¨
aten aus einem Prozessablauf in Aufrufe der von speziellen Anwendungssystemen bereitgestellten Dienste umsetzt. Damit wird die Komponente zur Prozesssteuerung unabh¨
angiger von anwendungssystemspezifischen Details.
63
4 Standards f¨
ur Informationssystemarchitekturen
a)
d)
b)
c)
e)
Abbildung 4.18: EAI-Architekturmuster (Quelle: [Lutz 2000])
Ein Vorgehens-Referenzmodell f¨
ur EAI
Im bereits mehrfach referenzierten [Linthicum 2000b] wird auch ein Vorgehens-Referenzmodell
zur Herstellung von EAI beschrieben. Es besteht aus zw¨
olf Schritten (¨
ubersetzt aus [Linthicum
2000b], S. 92, erg¨
anzend siehe auch [Allen 2001]):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
64
Verstehen des Unternehmens und des Problembereiches
Zusammenh¨
ange der Daten verstehen
Zusammenh¨
ange der Prozesse verstehen
Ermitteln aller Anwendungssystemschnittstellen
Ermitteln der Gesch¨
aftsereignisse
Ermitteln der Datentransformationsszenarios
Zuordnung der Informationsbewegungen
Anwenden der Technologie
Testen, Testen, Testen
Ber¨
ucksichtigen der Leistungsf¨
ahigkeit
Definieren des Nutzens
Festlegung von Wartungsmaßnahmen
4.4 Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen
4.4.4 The Open Group Architectural Framework, Version 8
The Open Group Architectural Framework, Version 8, ist eine im Vergleich zur Version 7
(vgl. Abschnitt 4.2.5) wesentlich erweiterte und u
¨ berarbeitete TOGAF-Version (im Folgenden
abgek¨
urzt mit TOGAF8). Darin werden u. a. die Bez¨
uge der Informationssystemarchitektur
zur Unternehmensarchitektur ber¨
ucksichtigt.
Die zentralen Inhalte von TOGAF8 sind
– die TOGAF Architecture Development Method (TOGAF ADM),
– das TOGAF Enterprise Continuum (TOGAF EC) und
– die TOGAF Resource Base (TOGAF RB).
Die TOGAF Architecture Development Method
Die TOGAF ADM in der Version 8 ist ein Vorgehens-Referenzmodell zur Entwicklung und Weiterentwicklung von Unternehmens- und Informationssystemarchitekturen. Sie enth¨
alt mehrere
Phasen, von denen, im Unterschied zur Version 7, nicht nur eine, sondern mehrere Phasen der
Architekturentwicklung gewidmet sind. Die Phasen sind (¨
ubersetzt aus [The Open Group
2003], Part II):
Abbildung 4.19: Die Phasen der TOGAF Architecture Development Method und die Schritte der Phase D (Quelle:
[The Open Group 2003], Part II, Introduction, Figure 2)
65
4 Standards f¨
ur Informationssystemarchitekturen
a)
b)
Abbildung 4.20: Architekturkontinuum (a) und L¨
osungskontinuum (b) in TOGAF, Version 8 (Quelle: [The Open
Group 2003], Part III, Enterprise Continuum in Detail, Architecture Continuum, Figure 1 und Solutions Continuum,
Figure 3)
–
–
–
–
–
–
–
–
–
Vorbereitende Phase: Rahmenbedingungen und Grunds¨
atze
Phase A: Architekturvision,
Phase B: Unternehmensarchitektur,
Phase C: Informationssystemarchitekturen,
Phase D: Technologiearchitektur,
Phase E: M¨
oglichkeiten und L¨
osungen,
Phase F: Migrationsplanung,
Phase G: Implementierungs¨
uberwachung und
Phase H: Architekturver¨
anderungsmanagement.
Jede Phase der TOGAF ADM ist unterteilt in Arbeitsschritte (Abbildung 4.19). Phase D
besteht beispielsweise aus acht Schritten (¨
ubersetzt aus [The Open Group 2003], Part II,
Phase D):
1.
2.
3.
4.
5.
6.
7.
8.
Erstellung einer Basisbeschreibung im TOGAF-Format,
Ber¨
ucksichtigung verschiedener Architektur-Referenzmodelle, Sichten und Werkzeuge,
Erstellung eines Architekturmodells aus Bausteinen,
Auswahl der von den Bausteinen ben¨
otigten Dienste,
¨
Uberpr¨
ufung der Einhaltung von Unternehmenszielen,
Bestimmung der Kriterien f¨
ur die Spezifikationsauswahl,
Vervollst¨
andigung der Architekturdefinition und
Durchf¨
uhrung einer Diskrepanzanalyse.
Das TOGAF Enterprise Continuum
Das TOGAF Enterprise Continuum (TOGAF EC) erg¨
anzt die TOGAF ADM um Informationen bzw. Anleitungen zur Einordnung und Wiederverwendung von Architektur-Referenzmodellen
und anderen Materialien zur Architekturentwicklung ([The Open Group 2003], Part III).
Diese Anleitungen sind aufgeteilt auf
– ein Architekturkontinuum (Architecture Continuum) und
– ein L¨
osungskontinuum (Solutions Continuum).
66
4.4 Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen
a)
c)
b)
d)
Abbildung 4.21: TOGAF TRM in TOGAF, Version 8, (a und b) und Ableitung der Elemente des TOGAF III-RM aus
dem TOGAF TRM (c und d) (Quellen: [The Open Group 2003], Part III, Foundation Architecture: Technical Reference
Model, High-level Breakdown, Figure 1, und TRM in Detail, Figure 1, [The Open Group 2003], Part III, Integrated
Information Infrastructure Reference Model, High-Level View, Figure 2b und Figure 3)
Im Architekturkontinuum werden vier Architekturtypen in einer Folge zueinander in Beziehung gesetzt. Die Folge verdeutlicht ein Entwicklungsprinzip, nach dem unternehmensspezifische Architekturen (enterprise architectures, organization architectures) aus anwendungsbereichsspezifischen Architekturen (industry architectures), diese aus anwendungsbereichs¨
ubergreifenden Architekturen mit Bezug zu bestimmten Diensten (common system architectures)
und diese aus grundlegenden Architekturen (foundation architectures) entwickelt werden (Ab-
67
4 Standards f¨
ur Informationssystemarchitekturen
bildung 4.20a). Im TOGAF selbst werden auch eine grundlegende Architektur, die TOGAF
Foundation Architecture, bestehend aus
– dem TOGAF Technical Reference Model (TOGAF TRM) und
– der TOGAF Standards Information Base (TOGAF SIB),
sowie eine anwendungsbereichs¨
ubergreifende Architektur mit Bezug zum Konzept des gren”
zenlosen Informationsflusses“ ( boundaryless information flow“),
”
– das TOGAF Integrated Information Infrastructure Reference Model (TOGAF III-RM),
beschrieben.
Im L¨
osungskontinuum werden die zu den Architekturtypen des Architekturkontinuums zugeh¨
origen L¨
osungstypen zueinander in Beziehung gesetzt: unternehmensspezifische L¨
osungen
(organization solutions) werden aus anwendungsbereichsspezifischen L¨
osungen (industry solutions), diese aus anwendungsbereichs¨
ubergreifenden Systeml¨
osungen (systems solutions), diese
aus Produkten und Diensten (products and services) entwickelt (Abbildung 4.20b).
Das TOGAF Technical Reference Model und die TOGAF Standards Information Base
Das bereits in Abschnitt 4.2.5 vorgestellte TOGAF TRM ist eine grundlegende Architektur zum entsprechenden Architekturtyp im Architekturkontinuum. Es ist ein ArchitekturReferenzmodell, das keinen Bezug zu bestimmten Anwendungsbereichen oder bestimmten
dienstbezogenen anwendungsbereichs¨
ubergreifenden Ans¨
atzen hat (Abbildung 4.21a und b,
vgl. Abschnitt 4.2.5). Die TOGAF SIB gibt Standards f¨
ur die Dienstkategorien aus dem TOGAF TRM an (vgl. Abschnitt 4.2.5).
Das TOGAF Integrated Information Infrastructure Reference Model
Das TOGAF III-RM ist eine anwendungsbereichs¨
ubergreifende Architektur zum entsprechenden Architekturtypen im Architekturkontinuum. Es ist ein Architektur-Referenzmodell, das
das Konzept des grenzenlosen Informationsflusses“ (boundaryless information flow) bzw. ei”
ne zugeh¨
orige Architektur, die Integrated Information Infrastructure (III), in den Mittelpunkt
stellt. Entsprechend dem Architekturkontinuum enth¨
alt und erweitert das TOGAF III-RM Elemente des TOGAF TRM (Abbildung 4.21). F¨
ur eine ausf¨
uhrlichere Vorstellung des TOGAF
III-RM sei hier auf [The Open Group 2003], Part III, Integrated Information Infrastructure
Reference Model verwiesen.
4.4.5 Enterprise Application Planning
Das letzte hier vorgestellte Rahmenwerk ist der Ansatz Enterprise Application Planning (EAP)
von S. H. Spewak ([Spewak and Hill 1992]). Er beschreibt ein Vorgehens-Referenzmodell f¨
ur
den Entwurf und die Entwicklungsplanung von Informationssystemarchitekturen.
Enterprise Architecture Planning is the Process of defining architectures for the use of information in
”
support of the business and the plan for implementing those architectures.“ ([Spewak and Hill 1992], S. 1)
EAP ist ausd¨
ucklich auf die ersten beiden Sichten im Zachman-Rahmenwerk bezogen.
Das Vorgehensmodell besteht aus sieben Phasen, aufgeteilt auf vier Ebenen (Abbildung 4.22).
Die Phasen sind (¨
ubersetzt aus [Spewak and Hill 1992], S. 13-17):
68
4.4 Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen
Abbildung 4.22: Phasen des Enterprise Architecture Planning (Quelle: [Spewak and Hill 1992], S. 13, Figure 1.7)
Ebene 1–Wo wir starten
Phase1: Planungsbeginn. Starten des EAP auf dem richtigen Weg, einschließlich der zu nutzenden Methodologie,
der beteiligten Personen und der zu nutzenden Werkzeuge. Das f¨
uhrt zur Erstellung eines Arbeitsplans f¨
ur
EAP und zur Sicherung der Zustimmung des Managements zum Durchlaufen der folgenden sechs Phasen.
Ebene 2–Wo wir sind
Phase 2: Unternehmensmodellierung. Stellt eine Wissensbasis u
¨ber das Unternehmen und die im Unternehmensbetrieb verwendeten Informationen zusammen.
Phase 3: Aktuelle Systeme & Technologie. Bestimmt, welche Anwendungssysteme und unterst¨
utzenden Technologieplattformen vorhanden sind. Das ist eine zusammenfassende Bestandsaufnahme der Anwendungssysteme,
Daten und Technologieplattformen, um eine Basis f¨
ur langfristige Migrationspl¨
ane bereitzustellen.
Ebene 3–Wo wir zuk¨
unftig sein wollen
Phase 4: Datenarchitektur. Bestimmt die wichtigsten Arten von Daten, die im Unternehmen ben¨
otigt werden.
Phase 5:Anwendungssystemarchitektur. Bestimmt die wichtigsten Arten von Anwendungssystemen, die zur Verwaltung der Daten zur Erf¨
ullung der Unternehmensaufgaben ben¨
otigt werden.
Phase 6: Technologiearchitektur. Bestimmt die Technologieplattformen, die ben¨
otigt werden, um eine Umgebung f¨
ur die Anwendungssysteme, die die Daten verwalten und die Unternehmensaufgaben unterst¨
utzen,
bereitzustellen.
Ebene 4–Wie wir dahin kommen
Phase 7:
me,
den
Implementierungs-/Migrationspl¨
ane. Bestimmt die Reihenfolge der Einf¨
uhrung der Anwendungssysteerstellt einen Terminplan f¨
ur die Einf¨
uhrung, eine Kosten-Nutzen-Analyse und einen klaren Pfad f¨
ur
¨
Ubergang
vom aktuellen Stand zum gew¨
unschten Stand.
Jede der sieben Phasen ist in Schritte unterteilt, zu denen jeweils Aufgaben und Richtlinien
zu deren Erf¨
ullung beschrieben werden. Einige Aufgaben sind unmittelbar mit bestimmten
Methoden, z. B. der Entity-Relationship-Modellierung, verkn¨
upft (Siehe K¨
asten Schritte der
”
EAP-Phasen . . .“).
69
4 Standards f¨
ur Informationssystemarchitekturen
Kasten 4.6: Schritte der EAP-Phasen und Beispiele f¨
ur zugeh¨
orige
Gegenst¨
ande, erwartete Ergebnisse, Aufgaben und Richtlinien
Phase 1: Planungsbeginn
Schritt 1: Ermittlung des Anwendungsbereiches und der Ziele f¨
ur die Enterprise Application Planning
Schritt 2: Entwicklung einer Zielvorstellung
Schritt 3: Adaptierung einer Planungsmethodik
Schritt 4: Bereitstellung von Rechnerressourcen f¨
ur die Planung
Schritt 5: Zusammenstellung des Planungsteams
Schritt 6: Vorbereitung des EAP-Arbeitsplans
Schritt 7: Einholung der Zustimmung der Unternehmensleitung
Phase 2A: Vorbereitendes Unternehmensmodell
Schritt 1: Dokumentation der Organisationsstruktur
Gegenstand
Gegenstand dieses Schrittes ist es, die Organisationsstruktur zu dokumentieren und Personen und Standorte zu ermitteln, die Unternehmensaufgaben erf¨
ullen. Es gibt zwei wichtige Verwendungen f¨
ur diese
Informationen in EAP: (1) die Ermittlung von Personen, die w¨
ahrend der Unternehmensbefragung befragt werden m¨
ussen, und (2) die Bestimmung des Ausmaßes der gemeinsamen Nutzung von Daten und
Anwendungssystemen. (. . . )
Erwartete Ergebnisse
1. aktuelle Organisationsdiagramme
2. Liste der Positionen und Titel inkl. der Standorte, wo sie auftreten, und die Anzahlen der Personen
in den betreffenden Positionen
3. Dokumentation der Unternehmensziele und der strategischen Gesch¨
aftspl¨
ane
4. Eingabe der genannten Informationen in das Planungswerkzeug und Berichterstellung
Aufgaben und Richtlinien
Aufgabe 1: Sammeln Sie aktuelle Organisationsdiagramme und geben Sie die Informationen in das Planungswerkzeug ein. Falls keine Organisationsdiagramme vorhanden oder die vorhandenen nicht aktuell
sind, zeichnen Sie sie und aktualisieren Sie sie. Die Diagramme sollten so viele der folgenden Informationen wie m¨
oglich beinhalten:
1. Abteilungen (Name und Ort)
2. Titel/Positionen
3. Personen (Name und Telefon)
4. Berichtswege (direkt und indirekt)
5. Anzahl der Personen in den Positionen oder Abteilungen.
(. . . )
Aufgabe 2: Ermitteln Sie Unternehmensstandorte und ordnen Sie sie Organisationseinheiten zu. (. . . )
Die folgenden Richtlinien k¨
onnen verwendet werden, um zu bestimmen, ob Unternehmensstandort
ein Attribut der Organisationseinheit oder eine eigene Struktur in der EAP-Datenbank sein sollte.
Unternehmensstandort sollte ein Attribut sein, wenn
• die meisten Unternehmensaufgaben an einem Standort oder in einer Stadt erf¨
ullt werden,
• die Organisationsstruktur an jedem Ort im Wesentlichen gleich ist oder
• jede Region oder jeder Ort eine unabh¨
angige Organisationsstruktur hat, bei der nur auf h¨
ochster Ebene an eine zentrale oder gemeinsame Organisationseinheit berichtet wird.
Unternehmensstandort sollte in einer eigenen Datenstruktur gespeichert werden, wenn (. . . )
Aufgabe 3: Dokumentieren Sie Unternehmensziele (optional). (. . . )
Aufgabe 4: Erstellen Sie Berichte u
¨ber die Organisationseinheiten, die Berichtsstruktur, die Standorte und
(optional) die Unternehmensziele. (. . . )
Schritt 2: Bestimmung der Aufgaben (. . . )
Schritt 3: Bekanntgabe des vorbereitenden Unternehmensmodells (. . . )
Phase 2B:
Schritt 1:
Schritt 2:
Schritt 3:
Schritt 4:
Schritt 5:
Unternehmensbefragung
Terminplanung f¨
ur Interviews
Vorbereitung der Interviews
Durchf¨
uhrung der Interviews
Eingabe der Daten in das Planungswerkzeug
Bekanntgabe des vollst¨
andigen Unternehmensmodells
(zusammengestellt und u
¨bersetzt aus [Spewak and Hill 1992])
70
4.4 Unternehmensbezogene Rahmenwerke f¨
ur Informationssystemarchitekturen
Kasten 4.7: Schritte der EAP-Phasen und Beispiele f¨
ur zugeh¨
orige
Gegenst¨
ande, erwartete Ergebnisse, Aufgaben und Richtlinien (Fortsetzung 1)
Phase 3: Aktuelle Systeme und Technologiearchitektur
Schritt 1: Bestimmung des Anwendungsbereiches, der Ziele und des Arbeitsplanes f¨
ur einen Ressourcenkatalog
Schritt 2: Vorbereitung der Datenerfassung
Schritt 3: Datenerfassung
Schritt 4: Datenregistrierung
Schritt 5: Validierung der Ressourcenkatalogdaten und Erstellung einer vorl¨
aufigen Version des Ressourcenkataloges
Schritt 6: Erstellung von Grafiken
Schritt 7: Bekanntgabe des Ressourcenkataloges
Schritt 8: Verwaltung und Wartung des Ressourcenkataloges
Phase 4: Datenarchitektur
Schritt 1: Auflistung von m¨
oglichen Dateneinheiten f¨
ur die nachfolgende Festlegung
Gegenstand
Gegenstand dieses Schrittes ist es, alle potentiellen Dateneinheiten zu ermitteln, die zur Unterst¨
utzung
des Unternehmens ben¨
otigt werden. (. . . )
Erwartetes Ergebnis
1. Liste der Namen der m¨
oglichen Dateneinheiten. Die Liste kann vorl¨
aufige Definitionen, Synonymkennzeichnungen, Hinweise auf Aufgaben, die die Daten verwenden, und Teammitglieder, die die
betreffenden Namen vorgeschlagen haben, beinhalten.
Aufgaben und Richtlinien
Aufgabe 1: Teilen Sie das Unternehmensmodell auf Teammitglieder auf. Um eine Liste von Einheiten zu
formulieren, sollte die folgende Dokumentation vollst¨
andig und f¨
ur das EAP-Team verf¨
ugbar sein:
Aufgabendefinitionen aus dem Unternehmensmodell, Formulare zu Informationsquellen, Beispiele
f¨
ur Informationen aus den Informationsquellen, Befragungsnotizen, (. . . ).
Teilen Sie dieses Material, unterteilt nach Aufgabenzugeh¨
origkeit, unter den EAP-Teammitgliedern
auf; das heißt, ein Mitglied kann die Produktfertigungsaufgabe bearbeiten, ein anderes die Personalverwaltungsaufgabe usw.
Aufgabe 2: Jedes Teammitglied erstellt eine Liste von Einheiten (Personen, Orte, Gegenst¨
ande, Begriffe, Ereignisse) f¨
ur die nachfolgende Festlegung. (. . . )
Aufgabe 3: F¨
ugen Sie die einzelnen Listen zusammen. (. . . )
Schritt 2: Festlegung der Dateneinheiten, Attribute und Beziehungen
Schritt 3: Zuordnung der Dateneinheiten zu Unternehmensaufgaben
Schritt 4: Bekanntgabe der Datenarchitektur
Phase 5: Anwendungssystemarchitektur
Schritt 1: Auflistung m¨
oglicher Anwendungssysteme
Schritt 2: Festlegung der Anwendungssysteme
Schritt 3: Zuordnung der Anwendungssysteme zu Unternehmensaufgaben
Schritt 4: Analyse der Auswirkungen auf vorhandene Anwendungssysteme
Schritt 5: Bekanntgabe der Anwendungssystemarchitektur
Phase 6: Technologiearchitektur
Schritt 1: Ermittlung der Technologieplattformen und -prinzipien
Schritt 2: Festlegung der Technologieplattformen und der Verteilung von Daten und Anwendungssystemen
Schritt 3: Zuordnung der Technologieplattformen zu Anwendungssystemen und Unternehmensaufgaben
Schritt 4: Bekanntgabe der Technologiearchitektur
Phase 7A:
Schritt 1:
Schritt 2:
Schritt 3:
Schritt 4:
Einf¨
uhrungsplan
Festlegung der Einf¨
uhrungsreihenfolge
Sch¨
atzung des Aufwandes und der ben¨
otigten Ressourcen sowie Erstellung eines Terminplanes
Sch¨
atzung von Kosten und Nutzen des Einf¨
uhrungsplanes
Bestimmung von Erfolgsfaktoren und Angabe von Empfehlungen
Phase 7B: Planungsabschluss
Schritt 1: Vorbereitung des endg¨
ultigen Berichtes
Schritt 2: Abschließende Pr¨
asentation f¨
ur die Unternehmensleitung
(zusammengestellt und u
¨bersetzt aus [Spewak and Hill 1992])
71
4 Standards f¨
ur Informationssystemarchitekturen
Kasten 4.8: Schritte der EAP-Phasen und Beispiele f¨
ur zugeh¨
orige
Gegenst¨
ande, erwartete Ergebnisse, Aufgaben und Richtlinien (Fortsetzung 2)
Phase 7C:
Schritt 1:
Schritt 2:
Schritt 3:
Schritt 4:
Schritt 5:
Schritt 6:
Schritt 7:
Schritt 8:
Schritt 9:
Schritt 10:
Schritt 11:
¨
Uberleitung
zur Einf¨
uhrung
¨
Planung der Uberleitung
Adaptierung eines Systementwicklungsansatzes
Bereitstellung von Rechnerressourcen f¨
ur die Einf¨
uhrung
¨
Uberarbeitung
der Architekturen
¨
Einleitung der organisatorischen Anderungen
Einstellung von Personal
Anbieten von Schulungen
Festlegung von Programmierstandards
Festlegung von Verfahrensstandards
Entwicklung eines detaillierten Terminplanes f¨
ur die ersten Anwendungssysteme
¨
Bekanntgabe der Beendigung der Uberleitung
(zusammengestellt und u
¨bersetzt aus [Spewak and Hill 1992])
4.5 Rahmenwerke und Architekturstile
Einige der vorgestellten Rahmenwerke und der zugeh¨
origen Standards enthalten Elemente, die
f¨
ur die Definition eines Architekturstiles geeignet sind (vgl. Abschnitt 3.3).
Der Standard ISO/IEC 10746-2 definiert Begriffe f¨
ur die Beschreibung offener verteilter
Informationssysteme (vgl. Abschnitt 4.2.2). Das OMG Object Model und das OMG Component Model definieren die meisten der im OMA Reference Model, in der CORBA und in
den erg¨
anzenden Standards f¨
ur einzelne Dienstkategorien vewendeten Begriffe (vgl. 4.2.3). Das
ARIS-Metamodell ist ein sehr umfassendes Metamodell, in dem Begriffe f¨
ur sehr viele Aspekte
von Informationssystemen zusammengestellt sind.
Das OMA Reference Model ist ein Architektur-Referenzmodell f¨
ur Architekturen mit Komponenten, die Dienste zur Verf¨
ugung stellen (vgl. Abschnitt 4.2.3). Auch die Ebenen des HIF,
erg¨
anzt um die Dienstgruppen der HISA, k¨
onnen als Architektur-Referenzmodell betrachtet
werden (vgl. Abschnitt 4.2.4). Gleiches gilt f¨
ur das TOGAF TRM (vgl. Abschnitt 4.2.5).
4.6 Vergleichbarkeit von Architekturstandards
Die Begriffsdefinitionen des RM-ODP, des OMG Object Models, des OMG Component Models
und das ARIS-Metamodell haben viele Gemeinsamkeiten. Begriffe wie Objekt, Schnittstelle oder
Ereignis werden u
¨ berall nahezu gleich definiert. Viele Begriffe aus dem Standard ISO/IEC
10746-2 f¨
ur die Spezifikation von Komponenten und die Beschreibung ihrer Interaktionen sind
¨
u. a. in der von der OMG definierten UML formalisiert enthalten (vgl. Kasten Uberblick
u
¨ ber
”
OMG-Standards . . .“ in Abschnitt 4.2.3).
¨
Eine formale Uberf¨
uhrung der Begriffsdefinitionen ist wegen vieler unterschiedlicher Details
und unterschiedlicher Ber¨
ucksichtigung verschiedener Aspekte von Informationssystemen nicht
¨
oder nur in sehr vereinfachter Weise m¨
oglich. Hier wird keine entsprechende Uberf¨
uhrungsvorschrift angegeben.
F¨
ur die genannten Architektur-Referenzmodelle gilt gleiches wie f¨
ur die Begriffsdefinitio¨
nen/Metamodelle: Ahnliche
Unterscheidungen von Ebenen und Dienstkategorien sowie ¨
ahnliche Spezifikationen von Diensten weisen auf grunds¨
atzliche Austauschbarkeit hin. Die Dienst-
72
4.6 Vergleichbarkeit von Architekturstandards
gruppen der HISA k¨
onnen beispielsweise prinzipiell durch die von der OMG spezifizierten
Dienste f¨
ur den Anwendungsbereich des Gesundheitswesens ersetzt werden. Unterschiedliche
¨
Details machen jedoch eine formale Uberf¨
uhrung sehr schwer.
F¨
ur einen formalen Vergleich von Integrationstechniken werden im Teil III verschieden Ans¨
atze vorgestellt. Sie k¨
onnen genutzt werden, um konkrete Anwendungen von Integrationstechniken in bestimmten Szenarios zu vergleichen. Einen Vergleich unabh¨
angig von einem konkreten Informationssystem kann auf der Basis eines Architektur-Referenzmodells erfolgen. Ein
f¨
ur den Vergleich geeignetes Architektur-Referenzmodell muss die in einem interessierenden
Anwendungsbereich typischerweise genutzten Komponenten enthalten. Die f¨
ur diese Komponenten existierenden Integrationsanforderungen m¨
ussen ebenfalls vorliegen. Durch Anpassung
des Referenzmodells hinsichtlich der Nutzung der zu vergleichenden Integrationstechniken k¨
onnen Modelle abgeleitet werden, auf deren Basis der Vergleich durchgef¨
uhrt wird.
¨
Ubersicht
uber Rahmenwerke und einige zugeh¨
orige Standards
¨
In den Tabellen 4.2 und 4.3 sind die vorgestellten Rahmenwerke hinsichtlich der verwendeten
Begriffsdefinitionen bzw. Metamodelle, der Unterscheidung von Sichtweisen auf die Informationssystemarchitektur und der Bereitstellung von Referenzmodellen gegen¨
ubergestellt.
73
74
VorgehensReferenzmodell
InformationsReferenzmodell
ArchitekturReferenzmodell
Sichtweisen
Terminologie /
Metamodell
Unterscheidung von 7 Schichten,
von denen jede die Funktionalit¨
at
der darunterliegenden nutzt:
– Anwendungssystemschicht
– Pr¨
asentationsschicht
– Sitzungsschicht
– Transportschicht
– Netzwerkschicht
– Daten¨
ubertragungsschicht
– physische Schicht
OSI-Referenzmodell
Spezifikationen der Datentypen f¨
ur
die Parameter der Operationen der
verschiedenen Schnittstellen; kein
Informationsmodell i. e. S.
Einf¨
uhrung des MDA Patterns und
Beschreibung von Modelltransformationen im MDA Guide unter
Ber¨
ucksichtigung der ebenfalls im
MDA Guide beschriebenen Sichtweisen
OMA Reference Model mit der
zentralen Komponente
– Object Request Broker (ORB)
und vier Schnittstellenkategorien:
– Objektdienste
– gemeinsame Dienste
– Anwendungsbereichsschnitt– stellen
– Anwendungssystemschnitt– stellen
OMG Object Model mit Begriffen
wie z. B
– Objekt
– Schnittstelle
– Operation
OMG Component Model mit
Begriffen wie z. B.
– Komponente
– Ereignistyp
– Ereignisquelle / -senke
Unterscheidung von drei
Sichtweisen im Model Drive
Architecture Guide (MDA Guide):
– rechnerunabh¨
angige Sicht
– plattformunabh¨
angige Sicht
– plattformabh¨
angige Sicht
Object Management
Architecture (OMA)
TOGAF Architecture Development
Method (TOGAF ADM) mit 7 Phasen:
A: Einleitung und Rahmenbedingungen
B: Basisbeschreibung
C: Zielarchitektur
D: M¨
oglichkeiten und L¨
osungen
E: Migrationsplanung
F: Implementierung
G: Architekturwartung
TOGAF Technical Reference Model
(TOGAF TRM) mit Unterscheidung
von drei Ebenen:
– Anwendungssystemebene
– Dienstebene, aufgeteilt auf ver– schiedene Dienstkategorien
– Kommunikationsinfrastrukurebene
The Open Group Architectural
Framework (TOGAF) 7
¨
Tabelle 4.2: Ubersicht
u
¨ber Rahmenwerke zu Informationssystemarchitekturen (Teil 1)
Unterscheidung von sieben Sichtweisen
in ISO/IEC 10746-3:
– Unternehmenssichtweise
– Informationssichtweise
– rechnerbezogene Sichtweise
– Konstruktionssichtweise
– technologische Sichtweise
Referenzmodell f¨
ur offene verteilte Informationsverarbeitung
(RM-ODP)
Begriffsdefinitionen in ISO/IEC
10746-2 mit Begriffen wie z. B.
– Objekt
– Komposition
– Aktion
– Schnittstelle
Unterscheidung von 3 Ebenen:
– Anwendungssystemebene
– Middlewareebene
– Daten¨
ubermittlungsebene
F¨
ur die Middlewareebene werden 6
Dienstkategorien spezifiziert:
– Dienste zum Gegenstand
– der Gesundheitsversorgung
– Dienste zu Gesundheits– charakteristika
– Dienste zu Aktivit¨
aten
– Dienste zu Ressourcen
– Dienste zur Autorisierung
– Dienste zu Begriffen
informationale Spezifikation der
Dienstkategorien
Healthcare Information
Framework (HIF)
4 Standards f¨
ur Informationssystemarchitekturen
InformationsReferenzmodell
VorgehensReferenzmodell
ArchitekturReferenzmodell
Sichtweisen
Terminologie /
Metamodell
–
–
–
–
–
Organisationssicht
Steuerungssicht
Datensicht
Funktionssicht
Leistungssicht
Zachman-Rahmenwerk
Vorgehens-Referenzmodell nach [Linthicum
2000b] mit 12 Schritten:
– Verstehen des Problembereiches
– Zusammenh¨
ange der Daten verstehen
– Zusammenh¨
ange der Prozesse verstehen
– Ermitteln aller Anwendungssystemschnitt– stellen
– Ermitteln aller Gesch¨
aftsereignisse
– Ermitteln der Datentransformationsszenarios
– Zuordnung der Informationsbewegungen
– Anwenden der Technologie
– Testen, Testen, Testen
– Ber¨
ucksichtigen der Leisungsf¨
ahigkeit
– Definieren des Nutzens
– Festlegung von Wartungsmaßnahmen
Die von verschiedenen Autoren definierten
EAI-Ebenen implizieren i. d. R. eine Unterscheidung verschiedener Komponententypen,
also jeweils ein Architektur-Referenzmodell.
Ebenen nach [Linthicum 2000b]:
– Daten-EAI
– (Komponententyp: Datenbank)
– Anwendungssystemschnittstellen-EAI
– (Komponententyp: Anwendungssystem)
– Methoden-EAI
– (Komponententyp: Anwendungssystem)
– Benutzungsschnittstellen-EAI
– (Komponententyp: Benutzungsschnittstelle)
Enterprise Application Integration (EAI)
TOGAF Architecture Development
Method (TOGAF ADM) mit 1+8
Phasen:
– Vorbereitung: Rahmenbedingungen
– Vorbereitung: und Grunds¨
atze
– A: Architekturvision
– B: Unternehmensarchitektur
– C: Informationssystem– C: architekturen
– D: Technologiearchitektur
– E: M¨
oglichkeiten und L¨
osungen
– F: Migrationsplanung
– G: Implementierungssteuerung
– H: Architekturver¨
anderungs– H:management
TOGAF Technical Reference Model
(TOGAF TRM) mit Unterscheidung
von drei Ebenen:
– Anwendungssystemebene
– Dienstebene, aufgeteilt auf ver– schiedene Dienstkategorien
– Kommunikationsinfrastrukurebene
The Open Group Architectural
Framework (TOGAF) 8
¨
Tabelle 4.3: Ubersicht
u
¨ber Rahmenwerke zu Informationssystemarchitekturen (Teil 2)
ARIS-Phasenmodell mit 4 sich
gegenseitig r¨
uckkoppelnden
Phasen:
– Prozessgestaltung
– Prozessplanung und -steuerung
– Workflowsteuerung
– Anwendungssystem(-entwurf)
Architektur integrierter
Informationssysteme (ARIS)
ARIS-Metamodell (= ARIS-Informationsmodell) mit Begriffen wie
z. B.
– Organisationseinheit
– Funktion
– Modul
– Informationsobjekt
– Relation
– Klasse
– Ereignis
– Nachricht
Unterscheidung der 5 Sichtweisen
– Anwendungsbereichs– beschreibung
– Unternehmensmodell
– Informationssystemmodell
– technisches Modell
– detaillierte Beschreibung,
jeweils unterteilt in
– Datenbeschreibung
– Prozessbeschreibung
– Netzwerkbeschreibung
Vorgehens-Referenzmodell nach
[Spewak and Hill 1992] mit
7 Phasen auf 3 Ebenen:
• Ebene 1 (Start):
– Planungsbeginn
• Ebene 2 (IST-Zustand):
– Unternehmensmodellierung
– Aktuelle Systeme & Techno– logie
• Ebene 3 (SOLL-Zustand):
– Datenarchitektur
– Anwendungssystemarchitektur
– Technologiearchitektur
• Ebene 4 (Migrationsplan):
– Implementierungs-/Migrations– pl¨
ane
Enterprise Architecture
Planning (EAP)
4.6 Vergleichbarkeit von Architekturstandards
75
5 Gesch¨
aftsprozessmodellierung — Eine Einf¨
uhrung
5.1 Vorbemerkungen
Dieses Kapitel stellt kurz drei Ans¨
atze zur Gesch¨
aftsprozessmodellierung vor: die Methode der
Ereignisgesteuerten Prozessketten (EPK), die Business Process Modeling Language (BPML)
und das Semantische Objektmodell (SOM). Mit der bisherigen unmittelbaren Fokussierung
der Arbeit auf die Informationssystemarchitektur mag dieses eingeschobene“ Kapitel zun¨
achst
”
u
¨ berraschen; der Zusammenhang kann jedoch leicht hergestellt werden.
Die in Abschnitt 4.4 vorgestellten unternehmensbezogenen Rahmenwerke beschreiben Beziehungen zwischen Unternehmensaufgaben bzw. Gesch¨
aftsprozessen und der Informationssystemarchitektur im engeren Sinn (vgl. Definition zu Architekturmodell im Kasten Grund”
begriffe (5)“ in Abschnitt 3.4). Die Beziehungen k¨
onnen beispielsweise durch Unterscheidung
von unternehmensbezogenen und technischen Sichtweisen, z. B. in der Architektur integrierter Informationssysteme (ARIS) und im Zachman-Rahmenwerk, oder durch Unterscheidung
von unternehmensbezogenen und informationssystembezogenen Entwicklungsphasen, z. B. im
The Open Group Architectural Framework (TOGAF), Version 8, und im Enterprise Application Planning (EAP), ausgedr¨
uckt werden. In den unterschiedlichen Werken ist dabei die
Verkn¨
upfung der unternehmensbezogenen und der technischen Aspekte unterschiedlich ausf¨
uhrlich beschrieben.
Auch das in dieser Arbeit im Vordergrund stehende Metamodell 3LGM2 unterscheidet eine
¨
unternehmensbezogene fachliche Ebene von zwei technikbezogenen Werkzeugebenen. Uber
verschiedene Assoziationsbeziehungen wurden die Beziehungen zwischen den Ebenen formalisiert
¨
(Kapitel 6). Bei der Uberarbeitung
des 3LGM2 in Kapitel 7 wird u. a. der Begriff Ereignistyp ber¨
ucksichtigt1 , der sowohl in der Gesch¨
aftsprozessmodellierung als auch in Standards f¨
ur
Informationssystemarchitekturen verwendet wird.
5.2 Ereignisgesteuerte Prozessketten
Die Methode der Ereignisgesteuerten Prozessketten (EPK) ist nicht nur, aber auch, durch die
enge Verkn¨
upfung mit der ARIS zu einem bekannten Ansatz f¨
ur die Gesch¨
aftsprozessmodellierung geworden ([Keller et al. 1992], [Scheer et al. 1995], [Langner et al. 1997], [Scheer
1998b], vgl. Abschnitt 4.4.2).
Grundlage f¨
ur die Methode der EPK sind die Begriffe
– Funktion und
– Ereignis.
Das der Methode zugrunde liegende Verst¨
andnis der beiden Begriffe sei hier durch die folgenden
kurzen Zitate beschrieben:
1
Der Begriff Ereignistyp ist bereits in der zugrunde gelegten Version 2 des 3LGM2 enthalten. Seine Beziehungen
zu den anderen Elementen des 3LGM2 werden jedoch u
¨ berarbeitet.
77
5 Gesch¨
aftsprozessmodellierung — Eine Einf¨
uhrung
Abbildung 5.1: Beispiel f¨
ur eine EPK (Quelle: [Langner et al. 1997], S. 481, Abb. 1)
78
5.3 Die Business Process Modeling Language
(. . . ) wird der Funktionsbegriff im Sinne der Aufgabe verwendet, d. h. es stellt eine durch physische oder
”
geistige Aktivit¨
aten zu verwirklichende Soll-Leistung dar.“ ([Keller et al. 1992], S. 8)
Ein Ereignis ist in Anlehnung an die DIN 69900 das Eingetretensein eines definierten Zustandes, der eine
”
Folge von Aktivit¨
aten bewirkt.“ ([Keller et al. 1992], S. 10)
Der Zusammenhang zwischen Funktionen und Ereignissen kann folgendermaßen zusammengefasst werden: Das Beenden einer Funktionsausf¨
uhrung entspricht dem Eintreten eines Ereignisses, welches wiederum Bedingung f¨
ur das Ausf¨
uhren nachfolgender Funktionen sein kann.
Weitere wichtige Elemente von EPK sind boolesche Konnektoren (Abbildung 5.1).
Die Funktionen und Ereignisse von EPK haben Typcharacter. Die Elemente einer EPK sind
also nicht einzelne, bei konkreten Prozessausf¨
uhrungen (Prozessinstanzen) durchgef¨
uhrte Aktivit¨
aten und eintretende Ereignisse, sondern Typen, die in konkreten Prozessausf¨
uhrungen
ausgepr¨
agt werden. Die Auspr¨
agungen k¨
onnen dabei abh¨
angig von den durch einen Prozess
verarbeiteten Informationen variieren: Beispielsweise k¨
onnten die unterschiedlichen Ereignisse 500 Mullbinden angefordert“ und 1000 Mullbinden angefordert“ Auspr¨
agungen desselben
”
”
Typs sein. In [Keller et al. 1992], S. 11 wird dazu ausdr¨
ucklich auf den Zusammenhang
zwischen den Informationsobjekten in einem Datenmodell f¨
ur den betrachteten Anwendungsbereich und den Ereignistypen hingewiesen.
5.3 Die Business Process Modeling Language
Die Business Process Modeling Language (BPML) wurde von der Business Process Management Initiative (BPMI) entwickelt. Zur BPMI geh¨
oren verschiedene bekannte Unternehmen,
darunter Adobe Systems, IDS Scheer, Popkin Software, SAP oder SeeBeyond2 .
Die BPML definiert Begriffe f¨
ur die Beschreibung von Prozessen und gibt auf der Basis
einer XML-¨
ahnlichen Grammatik eine Syntax f¨
ur die Nutzung der Begriffe an ([BPMI BPML
WG 2002]). Dokumente zur Prozessbeschreibung werden also in einer XML-¨
ahnlichen Sprache
verfasst. Wesentliche Begriffe der BPML sind u. a.
–
–
–
–
–
Aktivit¨
at (activity),
Aktivit¨
atstyp (activity type),
Prozess (process),
Kontext (context) und
Signal (signal).
F¨
ur Aktivit¨
aten werden verschiedene Typen unterschieden, z. B. Aktion (action), Zuweisung
(assign) oder Aufruf (call). Die Syntax f¨
ur Aktivit¨
aten wird beispielsweise folgendermaßen
definiert ([BPMI BPML WG 2002], S. 13):
<{activity type}
name = NCName
{other attributes}>
Content: (documentation?, {other element}*)
</{activity type}>
Abbildung 5.2 zeigt ein Beispiel f¨
ur eine Prozessbeschreibung mit der BPML.
2
Der einleitende Text basiert auf den Angaben der BPMI, die im Februar 2005 unter der Internet-Adresse
www.bpmi.org verf¨
ugbar waren.
79
5 Gesch¨
aftsprozessmodellierung — Eine Einf¨
uhrung
<wsdl:message name="requestMessage">
<wsdl:part name="orderID" element="type:orderID"/>
<wsdl:part name="sender" element="type:senderService"/>
<wsdl:part name="details" element="type:orderDetails"/>
</wsdl:message>
. . .
<wsdl:portType name="exampleServiceType">
<wsdl:operation name="request">
<wsdl:input message="srv:requestMessage"/>
</wsdl:operation>
<wsdl:operation name="cancel">
<wsdl:input message="srv:cancelMessage"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:message name="acceptMessage">
<wsdl:part name="orderID" element="type:orderID"/>
</wsdl:message>
. . .
<bpml:process name="example">
<bpml:event activity="receiveRequest"/>
<bpml:context>
<bpml:property name="orderID" type="type:identifier"/>
<bpml:property name="customerService" type="inst:service"/>
<bpml:property name="orderDetails" element="type:orderDetails"/>
<bpml:property name="invoiceDetails" element="type:invoiceDetails"/>
</bpml:context>
<bpml:action name="receiveRequest"
portType="srv:exampleServiceType" operation="request">
<bpml:input element="type:orderID"
property="bp:orderID"/>
<bpml:input element="type:senderService"
property="bp:customerService"/>
<bpml:input element="type:orderDetails"
property="bp:orderDetails"/>
</bpml:action>
<bpml:sequence>
. . .
<bpml:action name="sendAcceptance"
portType="srv:customerServiceType" operation="accept"
locate="bp:customerService">
<bpml:output element="type:orderID">
<bpml:source property="bp:orderID"/>
</bpml:output>
</bpml:action>
. . .
</bpml:sequence>
<bpml:action name="sendInvoice" . . .>
. . .
</bpml:action>
</bpml:process>
Abbildung 5.2: Beispiel f¨
ur eine Prozessbeschreibung mit der BPML; die mit wsdl“ beginnenden Definitionen sind
”
WSDL-Definitionen f¨
ur Dienste (Quelle: [BPMI BPML WG 2002], S. 67-70, Beispiel 5)
80
5.4 Das Semantische Objektmodell
Abbildung 5.3: Beispiel f¨
ur eine mit der BPMN erstellte Prozessbeschreibung (Quelle: [BPMI Notation WG 2004],
S. 139, Abb. 87)
Auch die Elemente von BPML-Dokumenten haben wie die Elemente von EPK Typcharakter, auch wenn sie nicht ausdr¨
ucklich als Typen bezeichnet werden (vgl. Abschnitt 5.2). In
der BPML werden u. a. die Begriffe Ereignis (event) und Signal (signal) definiert. Der Begriff Signal hat dabei eine ¨
ahnliche Bedeutung wie der Begriff Ereignis in der Methode der
Ereignisgesteuerten Prozessketten (vgl. Abschnitt 5.2):
Signals are used to coordinate the execution of activities executing in the same context. For example, to
”
synchronize the start of one activity with the completion of another activity. Signals are also used to reflect
conditions that arise from the execution of activities, and to allow other activities executing in that context
to detect and react to these conditions.“ ([BPMI BPML WG 2002], S. 37)
Im Gegensatz zu EPK, bei denen Funktionstypen formal nur u
¨ ber zwischengeschaltete“ Er”
eignistypen zu einer Kette zusammengesetzt werden k¨
onnen, sieht die BPML f¨
ur einfache
Zusammenh¨
ange von Funktionen, z. B. Sequenzen, spezielle Sprachelemente vor.
Ereignisse in der BPML beschreiben das Erzeugen von Prozessinstanzen. Das Ereignisattribut eines Prozesses gibt an, ob Instanzen dieses Prozesses durch eine Aktivit¨
at, durch eine
Nachricht oder durch ein Signal erzeugt werden. Bei Instanziierung durch Nachrichten oder Signale werden mit dem Attribut zus¨
atzliche Aktivit¨
aten angegeben, die die betreffenden Nachrichten bzw. Signale senden bzw. anzeigen ([BPMI BPML WG 2002], S. 20-23).
Die BPML-Spezifikation sieht ausdr¨
ucklich vor, dass Dienstdefinitionen, die in der Web Services Description Language (WSDL) vorliegen, in den Prozessbeschreibungen genutzt werden
k¨
onnen (Abbildung 5.2, oberer Teil; [BPMI BPML WG 2002], S. 7, [W3C 2004]).
Erg¨
anzend zur BPML wurde von der BPMI bisher die Business Process Modeling Notation
(BPMN), eine grafische Sprache f¨
ur die Erstellung von Gesch¨
aftsprozessmodellen, herausgegeben (Abbildung 5.3). Weitere angek¨
undigte Spezifikationen, wie die Business Process Query
Language (BPQL), waren zum Zeitpunkt der Erstellung dieser Arbeit noch nicht verf¨
ugbar.
5.4 Das Semantische Objektmodell
Das Semantische Objektmodell (SOM) ist ein Ansatz zur prozessorientierten Betrachtung von
Unternehmensarchitekturen. Er stellt die Prozessmodellierung zu verschiedenen Ebenen der
81
5 Gesch¨
aftsprozessmodellierung — Eine Einf¨
uhrung
Abbildung 5.4: Ebenen der Unternehmensarchitektur im SOM-Ansatz (Quelle: [Ferstl and Sinz 1995], S. 212, Abb. 2)
Architekturbetrachtung in Beziehung und ist insofern mit der ARIS vergleichbar (vgl. Abschnitte 4.4.2 und 5.2). Die Ausf¨
uhrungen dieses Abschnittes basieren auf [Ferstl and Sinz
3
1995] .
Hinsichtlich der Unternehmensarchitektur werden im SOM-Ansatz drei Modellebenen unterschieden (Abbildung 5.44 ; [Ferstl and Sinz 1995], S. 212):
– der Unternehmensplan, der u. a. das betrachtete betriebliche System von seiner Umwelt abgrenzt, Unternehmensziele beschreibt und Strategien, z. B. die Marktstrategie,
bestimmt,
– die Gesch¨
aftsprozessmodelle, die L¨
osungsverfahren f¨
ur die Erf¨
ullung von Unternehmenszielen beschreiben, und
– die Anwendungssysteme, die als Teil der Ressourcen f¨
ur die Prozessabwicklung hinsicht¨
lich der Ubernahme
bestimmter (automatisierbarer) Anteile der Gesch¨
aftsprozesse spezifiziert werden.
Die sehr ausf¨
uhrlichen Definitionen und Erl¨
auterungen zur Gesch¨
aftsprozessmodellierung in
[Ferstl and Sinz 1995] sollen hier nicht wiedergegeben werden. Im Sinne der Abschnitte 5.2
und 5.3 werden die zentralen Begriffe zur Prozessbeschreibung genannt, die in einem Metamodell formal zueinander in Beziehung gesetzt werden (Abbildung 5.5):
–
–
–
–
–
Aufgabe,
Objekt,
Leistung,
Transaktion und
Ereignis
Die Begriffe spiegeln die in [Ferstl and Sinz 1995], S. 214 beschriebenen Sichten auf Ge3
4
Eine Einf¨
uhrung in den SOM-Ansatz wird u. a. auch in [Ferstl and Sinz 2001], S. 180-213 gegeben.
In der Abbildung zur Unternehmensarchitektur werden auf der dritten Ebene neben der AnwendungssystemArchitektur auch die Aufbauorganisation und die Anlagen-Architektur genannt. In den Ausf¨
uhrungen in
[Ferstl and Sinz 1995] werden die beiden letzteren nicht n¨
aher betrachtet.
82
5.4 Das Semantische Objektmodell
Abbildung 5.5: Metamodell f¨
ur die Gesch¨
aftsprozessmodellierung im SOM-Ansatz (Quelle: [Ferstl and Sinz 1995],
S. 216, Abb. 7)
sch¨
aftsprozesse wider:
– die Leistungssicht mit dem Schwerpunkt der Beauftragung und Lieferung von Leistungen
durch Gesch¨
aftsprozesse,
– die Lenkungssicht mit dem Schwerpunkt der Koordinierung von betrieblichen Objekten
¨
hinsichtlich der Erstellung und Ubergabe
von Leistungen und
– die Ablaufsicht mit dem Schwerpunkt der Ereignissteuerung der Aufgaben, die den betrieblichen Objekten zugeordnet sind.
Die ersten beiden Sichten werden dabei als strukturorientiert, die dritte als verhaltensorientiert
beschrieben.
Die Prozessmodellierung auf der Basis des SOM hat, wie die beiden anderen in diesem Kapitel
vorgestellten Ans¨
atze, Typcharakter: Es werden nicht einzelne Prozessausf¨
uhrungen betrachtet,
sondern die bei allen konkreten Abl¨
aufen immer wieder beteiligten Aufgaben, Ereignisse (im
Sinne von Ereignistypen) usw.
Der SOM-Ansatz sieht f¨
ur die strukturorientierte Prozessmodellierung Interaktionsmodelle,
f¨
ur die verhaltensorientierte Modellierung Vorgangs-Ereignis-Modelle vor5 . In den Interaktionsmodellen werden die oben genannten Begriffe Objekt und Transaktion verwendet. In den
Vorgangs-Ereignis-Modellen werden neben den Begriffen Objekt und Transaktion insbesondere
die Begriffe Aufgabe und Ereignis verwendet (Abbildung 5.6).
5
Ein Modell kann mehrere Schemata, z. B. mehrere Interaktionsschemata, enthalten.
83
5 Gesch¨
aftsprozessmodellierung — Eine Einf¨
uhrung
a)
b)
Abbildung 5.6: Beispiel f¨
ur ein Interaktionsmodell (a) und ein Vorgangs-Ereignis-Modell (b) (Quelle: [Ferstl and Sinz
1995], S. 218-219, Abb. 10 u. 12)
84
Teil II
Architekturmodellierung
85
6 Einf¨
uhrung in das 3LGM2
6.1 Vorbemerkungen
Das 3LGM2 ist ein Metamodell f¨
ur die Modellierung von Informationssystemen (vgl. Kasten
Grundbegriffe (4)“ im Kapitel 3). Es definiert Begriffe zur Beschreibung von Informationssys”
temen und Beziehungen zwischen den Begriffen. Das 3LGM2 wurde f¨
ur die Unterst¨
utzung des
Managements von Informationssystemen entwickelt, nicht f¨
ur die Spezifikation von Software
([Winter et al. 2001], [Winter et al. 2003], [Wendt et al. 2004]).
Im Vergleich zu anderen Werken, die Begriffe zur Informationssystembeschreibung definieren,
geh¨
oren zum 3LGM2 nur ca. 35 Begriffe. Im Standard ISO/IEC 10746-2 (vgl. Abschnitt 4.2.2),
der die Begriffe f¨
ur das Referenzmodell f¨
ur offene verteilte Informationsverarbeitung (RMODP) definiert, sind es dagegen ca. 100 Begriffe, im ARIS-Metamodell (vgl. Abschnitt 4.4.2)
sind es weit u
ur die Informa¨ ber 100 Begriffe. Durch die im 3LGM2 relativ geringe Anzahl der f¨
tionssystembeschreibung zul¨
assigen Begriffe ist die Ausdrucksf¨
ahigkeit hinsichtlich bestimmter
Details von Architekturen beschr¨
ankt. Diese m¨
oglicherweise zun¨
achst als Nachteil aufgefasste
Tatsache kann gleichzeitig als Vorteil hinsichtlich der Erlernbarkeit und der praktischen Anwendbarkeit angesehen werden. Beispiele f¨
ur die Anwendung des 3LGM2 werden in [Wendt
et al. 2004] und [Brigl et al. 2004] beschrieben.
In dieser Arbeit wird das 3LGM2 in der Version 2 (3LGM2 V2) angewendet und u
¨ berarbeitet
(siehe Kapitel 7 und Abschnitt 9.3.3). Diese Version enth¨
alt im Wesentlichen Vereinfachungen
im Vergleich zu der in [Winter et al. 2003] publizierten Version 1. Das 3LGM2 in der Version 1
¨
ist durch umfassende Uberarbeitung
des Metamodells 3LGM, das bereits 1995 publiziert wurde,
entstanden ([Winter and Haux 1995]).
6.2 Die Ebenen des 3LGM2 und ihre Hauptklassen
Die Begriffe des 3LGM2 sind auf 3 Ebenen aufgeteilt: Das 3LGM2 definiert
– eine fachliche Ebene,
– eine logische Werkzeugebene und
– eine physische Werkzeugebene
mit jeweils unterschiedlichen Klassen. Die Unterscheidung der drei Ebenen reflektiert die verbreitete Unterscheidung von Sichten auf die Informationssystemarchitektur (siehe Kapitel 4).
Dabei werden Beziehungen zwischen den Ebenen explizit durch Assoziationsbeziehungen beschrieben. Von den in Kapitel 4 beschriebenen Rahmenwerken enth¨
alt nur die ARIS im zugeh¨
origen ARIS-Metamodell vergleichbare Beziehungen.
Dieser Abschnitt (6.2) stellt zun¨
achst die Hauptklassen vor, die folgenden Abschnitte 6.3.1
und 6.3.2 stellen einige weitere Klassen vor, die in dieser Arbeit ben¨
otigt werden. Praktisch
n¨
utzliche Modelle werden selten ausschließlich aus Instanzen der Hauptklassen bestehen. Im
Gegenteil: Erst mit der Verwendung der weiteren Klassen werden die in den meisten Anwendungsf¨
allen interessierenden Details modelliert werden k¨
onnen. Die Hauptklassen werden hier
87
6 Einf¨
uhrung in das 3LGM2
hervorgehoben, da alle weiteren Klassen ohne sie nicht sinnvoll verwendet werden k¨
onnen.
6.2.1 Fachliche Ebene
Auf der fachlichen Ebene werden Aufgaben1 der Informationsverarbeitung sowie Objekttypen,
die bei der Erf¨
ullung der Aufgaben ben¨
otigt bzw. erzeugt werden, modelliert (Abbildung 6.1a).
Objekttypen k¨
onnen als Informationstypen verstanden werden.
Beispiele f¨
ur Aufgaben der Informationsverarbeitung im Krankenhaus sind die Befundung
von R¨
ontgenbildern, die Therapieplanung f¨
ur die Chemotherapie, die administrative Patientenaufnahme oder die Patientenabrechnung. Typische Objekttypen sind Patient, Fall, Befund
oder Diagnose (siehe auch Abbildung 6.1b).
6.2.2 Logische Werkzeugebene
Auf der logischen Werkzeugebene werden Anwendungsbausteine modelliert. Als Anwendungsbausteine werden Komponenten eines Informationssystems aufgefasst, die durch die Installation eines Softwareproduktes bzw. die (organisatorische) Installation eines Standardorganisationsplanes entstehen (Abbildung 6.2a).
Anwendungsbausteine, die durch Installation eines Softwareproduktes entstehen, werden
nach dem 3LGM2 als rechnerbasierte Anwendungsbausteine bezeichnet; Anwendungsbausteine, die durch Installation eines Standardorganisationsplanes entstehen, werden als
papierbasierte Anwendungsbausteine bezeichnet. Das Wort papierbasiert“ hat sich dabei
”
in der praktischen Anwendung als die am leichtesten vermittelbare Umschreibung f¨
ur die Tatsache, dass Personen unter Nutzung verschiedener physischer Hilfsmittel (siehe Abschnitt 6.2.3)
und geleitet durch einen Standardorganisationsplan bestimmte Aufgaben erf¨
ullen, erwiesen.
Beispiele f¨
ur rechnerbasierte Anwendungsbausteine sind ein digitales Bildarchiv oder ein
Patientenverwaltungssystem; ein Beispiel f¨
ur einen papierbasierten Anwendungsbaustein
ist ein Patientenkarteiverwaltungssystem in einer Ambulanz (siehe auch Abbildung 6.2b).
Die Bezeichnung Anwendungsbaustein (application component) spiegelt eine Informationssystembetrachtung wider, die die mehrfache Verwendung von Komponenten eines Informationssystems bei der Implementierung von Anwendungssystemen ber¨
ucksichtigt. Anwendungsbausteine k¨
onnen zu komplexen Anwendungssystemen zusammengesetzt werden, wobei die
Anwendungsbausteine, die mehrfach ben¨
otigte Funktionalit¨
aten bereitstellen, f¨
ur die Zusammensetzung mehrerer Anwendungssysteme verwendet werden k¨
onnen. Damit wird u. a. eine
Ann¨
aherung an Dienst- bzw. Schnittstellenkategorien, wie sie z. B. im OMA Reference Model (vgl. Abschnitt 4.2.3) oder im TOGAF Technical Reference Model (TOGAF TRM) (vgl.
Abschnitt 4.2.5) definiert werden, erreicht.
Anwendungsbausteine k¨
onnen u
¨ ber Anwendungsbausteinkonfigurationen zusammengefasst und den Aufgaben der fachlichen Ebene zugeordnet werden (Abbildung 6.2a). Eine Anwendungsbausteinkonfiguration ist eine Menge: Sie enth¨
alt bestimmte Anwendungsbausteine,
die gemeinsam das Erledigen einer bestimmten Aufgabe unterst¨
utzen. Eine einfache Visualisierung der Zuordnung von Anwendungsbausteinen zu Aufgaben zeigt Abbildung 6.4.
1
Klassennamen des 3LGM2 sind im Text in einer anderen Schriftart gesetzt.
88
6.2 Die Ebenen des 3LGM2 und ihre Hauptklassen
a)
b)
Abbildung 6.1: Spezifikationen der fachlichen Ebene des 3LGM2 mit der UML (vgl. [Winter et al. 2003], S. 546, Abb. 1)
(a) und Auszug der fachliche Ebene des Informationssystems des UKL (b)
89
6 Einf¨
uhrung in das 3LGM2
a)
b)
Abbildung 6.2: Spezifikationen der logischen Werkzeugebene des 3LGM2 mit der UML (vgl. [Winter et al. 2003], S. 547,
Abb. 3) (a) und Auszug der logischen Werkzeugebene des Informationssystems des UKL (b)
90
6.2 Die Ebenen des 3LGM2 und ihre Hauptklassen
a)
b)
Abbildung 6.3: Spezifikationen der physischen Werkzeugebene des 3LGM2 mit der UML (vgl. [Winter et al. 2003],
S. 548, Abb. 5) (a) und Auszug der physischen Werkzeugebene des Informationssystems des UKL (b)
91
6 Einf¨
uhrung in das 3LGM2
6.2.3 Physische Werkzeugebene
Auf der physischen Werkzeugebene werden konventionelle physische Datenverarbeitungsbausteine wie Karteischr¨
anke oder Transportfahrzeuge sowie elektronische physische Datenverarbeitungsbausteine wie Serversysteme oder PCs und ihre Netzverbindungen modelliert (Abbildung 6.3a und b).
Physische Datenverarbeitungsbausteine k¨
onnen u
¨ ber physische Datenverarbeitungsbausteinkonfigurationen zusammengefasst und den Anwendungsbausteinen der logischen
Werkzeugebene zugeordnet werden (Abbildung 6.3a). Eine physische Datenverarbeitungsbausteinkonfiguration ist eine Menge von physischen Datenverarbeitungsbausteinen,
auf denen ein bestimmter Anwendungsbaustein installiert ist. Eine einfache Visualisierung
der Zuordnung von physischen Datenverarbeitungsbausteinen zu Anwendungsbausteinen
zeigt Abbildung 6.4.
6.3 Klassen f¨
ur die Integrationsmodellierung
6.3.1 Klassen f¨
ur die Modellierung der Speicherung von Informationen
Die hier vorgestellten Klassen zur Modellierung der Speicherung von Informationen werden
nicht nur f¨
ur die Integrationsmodellierung verwendet. Sie k¨
onnen u. a. verwendet werden,
um die Aufteilung von Daten auf Anwendungssysteme und die Merkmale der verwendeten
Datenbanksysteme zu beschreiben. Die Beschreibung der Aufteilung von Daten auf Anwendungssysteme ist eine wesentliche Grundlage der Integrationsbewertung in Kapitel 9. Die daf¨
ur
vorgesehenen Klassen werden daher hier in einem Unterabschnitt zum Abschnitt Klassen f¨
ur
”
die Integrationsmodellierung“ vorgestellt.
Zur Modellierung der Speicherung von Informationen enth¨
alt das 3LGM2 die Klassen (Abbildung 6.2a)
– Anwendungsbaustein,
– Dokumententyp und
– Datenbankverwaltungssystem.
Die Speicherung von Daten in einem rechnerbasierten Anwendungsbaustein kann durch ein Datenbankverwaltungssystem gesteuert werden. Einem papierbasierten Anwendungsbaustein
k¨
onnen Dokumententypen zugeordnet werden, die zur Speicherung von Informationen verwendet werden.
Die Klasse Objekttyp auf der fachlichen Ebene ist mit den Klassen rechnerbasierter
Anwendungsbaustein und Dokumententyp u
¨ ber die Assoziationsbeziehungen wird_gespeichert_von verbunden.
An dieser Stelle sei die Assoziationsbeziehung hat_als_Master zwischen Objekttypen und
Anwendungsbausteinen hervorgehoben. Mit ihr kann ausgedr¨
uckt werden, ob ein Objekttyp, der in mehreren Anwendungsbausteinen gespeichert wird, einen sogenannten f¨
uhrenden
Anwendungsbaustein hat. Die Benennung eines f¨
uhrenden Anwendungsbausteines f¨
ur bestimmte Objekttypen ist dann wichtig, wenn zur Wahrung einer bestimmten Autonomie von
Anwendungsbausteinen akzeptiert wird, dass Abweichungen zwischen den in den Anwendungsbausteinen gespeicherten Auspr¨
agungen der betreffenden Objekttypen entstehen. Aktualisierungen von gespeicherten Daten m¨
ussen dann immer im Master-Anwendungsbaustein des
92
6.3 Klassen f¨
ur die Integrationsmodellierung
Abbildung 6.4: Auszug des Informationssystems des UKL in Drei-Ebenen-Darstellung
betreffenden Objekttyps erfolgen und von dort ausgehend, mit oder ohne Zeitversatz bzw.
Akzeptanz von Abweichungen, an die anderen Anwendungsbausteine verteilt werden.
93
6 Einf¨
uhrung in das 3LGM2
HL7-Ereignistyp
A01
A02
A03
A08
Beschreibung (Ausz¨
uge aus dem Standard)
3.2.1 ADT/ACK - admit / visit notification (event A01) An A01
”
event is intended to be used for “Admitted” patients only. An A01 event is sent
as a result of a patient undergoing the admission process which assigns the
patient to a bed. It signals the beginning of a patient’s stay in a healthcare
facility. Normally, this information is entered in the primary ADT system and
broadcast to the nursing units and ancillary systems. (. . . )“
3.2.2 ADT/ACK - transfer a patient (event A02) An A02 event is
”
issued as a result of the patient changing his or her assigned physical location.
(. . . )“
3.2.3 ADT/ACK - discharge/end visit (event A03) An A03 event sig”
nals the end of a patient’s stay in a healthcare facility. It signals that the
patient’s status has changed to “discharged” and that a discharge date has been
recorded. The patient is no longer in the facility.“
3.2.8 ADT/ACK - update patient information (event A08) This trig”
ger event is used when any patient information has changed but when no other
trigger event has occurred. For example, an A08 event can be used to notify
the receiving systems of a change of address or a name change. (. . . )“
Tabelle 6.1: Beispiele f¨
ur Ereignistypen im Kommunikationsstandard HL7 (Quelle: [HL7 1999])
¨
6.3.2 Klassen f¨
ur die Modellierung der Ubermittlung
von Informationen
Die im Folgenden vorgestellten Klassen erlauben eine einfache Integrationsmodellierung und
¨
bilden eine wichtige Grundlage f¨
ur die in Kapitel 7 unternommene Uberarbeitung
des 3LGM2
hinsichtlich komponentenbasierter Architekturmodellierung und f¨
ur die Integrationsbewertung
in den Kapiteln 9 und 11.
¨
Zur Modellierung der Ubermittlung
von Informationen enth¨
alt das 3LGM2 die Klassen (Abbildung 6.2a)
–
–
–
–
–
–
–
Benutzungsschnittstelle,
Bausteinschnittstelle,
Kommunikationsbeziehung,
Ereignistyp,
Nachrichtentyp,
Dokumententyp und
Kommunikationsstandard.
Die Klasse Benutzungsschnittstelle kann verwendet werden, um Kommunikation, d. h.
¨
Ubermittlung von Informationen, zwischen Anwendungsbausteinen und Benutzern auszudr¨
ucken.
Der Datenaustausch zwischen Anwendungsbausteinen wird durch das Zuweisen von Bausteinschnittstellen zu Anwendungsbausteinen und das Verkn¨
upfen der Bausteinschnittstellen u
¨ ber Assoziationen der Klasse Kommunikationsbeziehung modelliert. Zu einer Kommunikationsbeziehung geh¨
oren also immer zwei Bausteinschnittstellen, je eine am sendenden und eine am empfangenden Anwendungsbaustein. Diese Definition entspricht den
praktischen Realisierungen der meisten Kommunikationsbeziehungen, bei denen i. d. R. zwei
Schnittstellenmodule gekauft bzw. selbst programmiert werden m¨
ussen.
Bausteinschnittstellen k¨
onnen u
¨ ber Nachrichtentypen und deren Bezug zu bestimmten Ereignistypen oder Dokumententypen n¨
aher beschrieben werden (Tabelle 6.1 und Abbildung 6.5). Dazu geh¨
ort auch, sofern sinnvoll, der zugrunde liegende Kommunikationsstandard.
Die bereits in Abschnitt 6.3.1 vorgestellte Klasse Dokumententyp wird nicht nur f¨
ur die
Beschreibung papierbasierter Speicherung verwendet, sondern auch f¨
ur die Beschreibung pa-
94
6.4 Prozessmodellierung
pierbasierter Kommunikation.
6.4 Prozessmodellierung
Auf der Basis der in [Brigl et al. 2003] beschriebenen Erg¨
anzung des 3LGM2 kann eine einfache Modellierung von informationsverarbeitenden Prozessen unternommen werden. Sie ist eine
sehr vorsichtige“ Ann¨
aherung an die m¨
achtigen Methoden und Werkzeuge der Gesch¨
aftspro”
zessmodellierung, die dadurch nicht ersetzt werden sollen (vgl. Kapitel 5). Auch hier steht, im
Sinne der Ausf¨
uhrungen in Abschnitt 6.1, die Beschr¨
ankung der Theorie und des zugeh¨
origen
Vokabulars im Vordergrund.
Ein Informationsprozess ist eine Sequenz von Aufgaben, die bestimmte Bedingungen hinsichtlich der Interpretation und Bearbeitung von Objekttypen erf¨
ullen. Jede Aufgabe in einem
Informationsprozess, die nicht die erste Aufgabe dieses Informationsprozesses ist, muss
einen Objekttyp interpretieren, den eine vorhergehende Aufgabe desselben Informationsprozesses bearbeitet.
Aus Informationsprozessen kann u
¨ ber die Beziehungen zwischen den Elementen der fachlichen Ebene und der logischen Werkzeugebene abgeleitet werden, zwischen welchen Anwendungsbausteinen Objekttypen, d. h. Informationen, u
ussen. Eine ent¨ bermittelt werden m¨
sprechende Sequenz von Anwendungsbausteinen inkl. der beteiligten Bausteinschnittstellen wird als Kommunikationsprozess bezeichnet (Abbildung 6.6).
6.5 Das 3LGM2 und Architekturstile
Mit den Ausf¨
uhrungen der Abschnitte 3.3 und 3.4 sowie der vorhergehenden Abschnitte dieses
Kapitels kann das 3LGM2 als semantisches Modell f¨
ur Architekturstile aufgefasst werden. Die
folgenden Ausf¨
uhrungen erl¨
autern, basierend auf Abschnitt 3.3, diesen Gedanken.
Eine Syntax zur Erstellung von 3LGM2 -basierten Modellen wurde bisher nicht explizit definiert. Dem am Ende von Abschnitt 6.1 genannten urspr¨
unglichen 3LGM wurde eine graphenbasierte Notierung von Modellen zugrunde gelegt, u
uckt, Kompo¨ ber die, vereinfacht ausgedr¨
nenten als Knoten und Konnektoren als Kanten eines Graphen notiert wurden.
a)
b)
Abbildung 6.5: Kombinationen von Ereignistypen und Nachrichtentypen zur Beschreibung der Kommunikation zwischen den Anwendungsbausteinen Patientenverwaltungssystem und Kommunikationsserver am UKL
95
6 Einf¨
uhrung in das 3LGM2
Sowohl das zum urspr¨
unglichen 3LGM als auch das zum 3LGM2 entwickelte Modellierungswerkzeug pr¨
asentieren Modelle grafisch, basierend auf einer definierten Menge von Symbolen
(vgl. die Abbildungen von Modellbeispielen in diesem Kapitel, z. B. Abbildung 6.2b). F¨
ur die
¨
Elemente, die f¨
ur eine bessere Ubersicht
nicht grafisch dargestellt werden, stellen sie Listen zur
Verf¨
ugung (vgl. z. B. Abbildung 6.5). Das Erstellen von Konfigurationen im Sinne von Abschnitt 3.3 erfolgt unmittelbar durch das Erzeugen und Verkn¨
upfen von grafischen Elementen
bzw. durch das Erzeugen von Listeneintr¨
agen.
Die Semantik der grafischen Elemente und Listeneintr¨
age wird durch das 3LGM2 festgelegt. Die Klassennamen und die Namen der Assoziationsbeziehungen stehen f¨
ur bestimmte
Begriffe, die in Publikationen wie [Winter et al. 2003] oder [Wendt et al. 2004] erl¨
autert
werden. Die Klassen im 3LGM2 entsprechen Komponententypen, die Assoziationsbeziehungen
im 3LGM2 entsprechen Konnektorentypen. Durch die Verkn¨
upfung der 3LGM2 -Klassen u
¨ ber
die Assoziationsbeziehungen sind die zul¨
assigen Konfigurationen festgelegt.
Wenn Architekturmodellierung als Architekturmodellierung im weiteren Sinn entsprechend
Kasten Grundlagen (5)“ im Abschnitt 3.3 betrachtet wird, dann kann das vollst¨
andige 3LGM2
”
als ein semantisches Modell f¨
ur Architekturstile aufgefasst werden. Legt man die Definition
f¨
ur Architekturmodellierung im engeren Sinn zugrunde, dann entsprechen die 3LGM2 -Klassen
rechnerbasierter Anwendungsbaustein und papierbasierter Anwendungsbaustein den
zul¨
assigen Komponententypen und die Assoziationsbeziehung Kommunikationsbeziehung steht
f¨
ur den einzigen zul¨
assigen Konnektorentyp. Die u
¨ brigen Klassen und Assoziationsbeziehungen der logischen Werkzeugebene dienen dann der n¨
aheren Beschreibung der Auspr¨
agungen
der Komponenten- und Konnektorentypen.
¨
Abbildung 6.6: Ein Kommunikationsprozess zur Ubermittlung
von ADT-Informationen im Informationssystem des UKL
96
6.5 Das 3LGM2 und Architekturstile
Das 3LGM2 als Architekturstil
Das 3LGM2 wurde als generisches Metamodell entwickelt, das nicht auf einen bestimmten
Architekturstil zugeschnitten ist. Die hier vorgestellt Version 2 ist jedoch besonders f¨
ur solche
Architekturen geeignet, deren Komponenten durch Austausch von Nachrichten miteinander
kommunizieren (vgl. Abschnitt 6.3.2 und Abbildung 6.2a): Eine ausdr¨
uckliche Angabe, ob
bestimmte Kommunikationsbeziehungen synchron oder asynchron arbeiten, ist nicht m¨
oglich.
Eine ausdr¨
uckliche Benennung von Nachrichtentypen, die als Anfragen u
¨ bermittelt werden,
und Nachrichtentypen, die als Antwort zur¨
uck¨
ubermittelt werden, sowie ihre Verkn¨
upfung
zu Anfragetyp-Anworttyp-Paaren ist ebenfalls nicht m¨
oglich.
Durch die Beschr¨
ankungen in der Ausdruckf¨
ahigkeit des 3LGM2 k¨
onnen u. U. nicht alle
m¨
oglicherweise f¨
ur das Informationsmanagement relevanten Architekturen angemessen modelliert werden. Bevorzugt“ werden Architekturen mit nachrichtenbasierter Kommunikation oh”
ne Zusammenh¨
ange der u
onnen Zusammenh¨
ange im
¨ bermittelten Nachrichten. Beispielsweise k¨
Sinne von Parameter-Ergebnis-Paaren nicht oder nur sehr aufwendig ausgedr¨
uckt werden. Daur einen bestimmten Architekturstil betrachtet
mit kann das 3LGM2 als semantisches Modell f¨
werden.
Durch die Einf¨
uhrung der Klasse Operation in das 3LGM2 im Abschnitt 7.2.2 des folgenden
Kapitels wird eine flexiblere Kommunikationsmodellierung m¨
oglich.
97
¨
7 Flexible Architekturmodellierung — Uberarbeitung
des 3LGM2
7.1 Begriffe f¨
ur die Modellierung von Komponenten auf der Basis des 3LGM2
In den Abschnitten 3.2 und 3.3 wurde der Komponentenbegriff als zentrales Element von
Architekturen und Architekturstilen herausgearbeitet. In Abschnitt 6.5 wurde u. a. der Zusammenhang zwischen Komponententypen und 3LGM2 -Klassen beschrieben.
F¨
ur die weiteren Ausf¨
uhrungen wird die Definition f¨
ur Architekturmodell im engeren Sinn
zugrunde gelegt (vgl. Kasten Grundbegriffe (5)“ in Abschnitt 3.4). Die mit dem 3LGM2 model”
lierbaren Komponententypen werden also durch die Klassen rechnerbasierter Anwendungsbaustein und papierbasierter Anwendungsbaustein festgelegt (vgl. Abschnitt 6.5).
Standards wie das Referenzmodell f¨
ur offene verteilte Informationsverarbeitung (RM-ODP),
insbesondere Teil 2 Foundations“, das OMG Object Model oder das OMG Component Model,
”
die Sprachen f¨
ur die Beschreibung von interagierenden Komponenten definieren, legen eine
Vielzahl von Begriffen fest (vgl. Abschnitte 4.2.2 und 4.2.3). Viele davon werden f¨
ur eine
ausf¨
uhrliche Spezifikation, die dann in eine Implementierung m¨
undet, ben¨
otigt. Das 3LGM2
wurde nicht f¨
ur die ausf¨
uhrliche Softwarespezifikation entwickelt, sondern f¨
ur die Unterst¨
utzung
des Managements von Informationssystemen. Dabei wurde auch eine Beschr¨
ankung des durch
das 3LGM2 bereitgestellten Vokabulars angestrebt, um die Anwendung zu erleichtern (vgl.
Abschnitt 6.1).
Haupts¨
achlich aus den genannten Standards RM-ODP, OMG Object Model und OMG Component Model sowie aus der Methode der Ereignisgesteuerten Prozessketten (vgl. Abschnitt 5.2)
wurden die folgenden Begriffe ausgew¨
ahlt, die bei der Architekturbeschreibung mit Hilfe des
3LGM2 zur Verf¨
ugung stehen bzw. korrespondierende Begriffe haben sollten:
–
–
–
–
Objekt bzw. Komponente,
Ereignistyp,
Schnittstelle and
Operation.
Wie bereits beschrieben, werden ausf¨
uhrbare oder handelnde Komponenten als Anwendungsbausteine modelliert. Die f¨
ur die Modellierung der Interaktion von Anwendungsbausteinen
¨
ucksichtigung der genannten Begriffe wird
unternommene Uberarbeitung
des 3LGM2 unter Ber¨
im folgenden Abschnitt ausf¨
uhrlicher vorgestellt.
Das u
¨ berarbeitete 3LGM2 wird im Folgenden mit 3LGM2A bezeichnet. Das A weist auf die
¨
Uberarbeitung hinsichtlich der Architekurmodellierung hin.
¨
7.2 Uberarbeitung
des 3LGM2
7.2.1 Ereignistypen
Der Begriff Ereignistyp hat eine große Bedeutung f¨
ur die Modellierung von Prozessen. Er ist
bereits in der dieser Arbeit zugrunde gelegten Version 2 des 3LGM2 als Klasse enthalten. Seine
99
¨
7 Flexible Architekturmodellierung — Uberarbeitung
des 3LGM2
Einbettung in das 3LGM2 , d. h. seine Assoziationsbeziehungen zu anderen Klassen, wird hier
u
¨ berarbeitet.
Die Begriffe Ereignistyp, Ereignisquelle und Ereignissenke sind, neben anderen Begriffen,
wesentliche Elemente des OMG Component Models zur Beschreibung der Steuerung der Interaktion von Komponenten (vgl. Abschnitt 4.2.3).
Das RM-ODP enth¨
alt die Begriffe Ereignis und Ereignistyp nicht. F¨
ur das Benennen des
initiierenden Objektes und des reagierenden Objektes bzgl. einer bestimmten Kommunikation
werden die Rollen initiierendes Objekt (initiating object) und antwortendes Objekt (responding
object) definiert, f¨
ur das Benennen von Informationsquellen die Rolle produzierendes Objekt
ur das Benennen von Informationssenken die Rolle konsumierendes
(producer object) und f¨
Objekt (consumer object). Zus¨
atzlich werden die Rollen Client-Objekt (client object) und ServerObjekt (server object) definiert ([ISO/IEC JTC 1 1996b], S. 13, Definitionen 13.3.1-13.3.6).
Ereignistypen und Prozessmodellierung
An dieser Stelle wird die in Kapitel 5 kurz vorgestellte Modellierungswelt“ der Gesch¨aftspro”
¨
zessmodellierung in die Uberarbeitung
einbezogen. Bei der Vorstellung in Kapitel 5 wurde u. a.
die Bedeutung der Begriffe Ereignis und Ereignistyp hervorgehoben.
In Kommunikationsstandards wie HL7 werden die Begriffe Ereignis und Ereignistyp ebenfalls verwendet. In HL7 werden Ereignistypen im Zusammenhang mit Anwendungsf¨
allen
(use cases) definiert ([HL7 1999]). Die Anwendungsfallbeschreibungen k¨
onnen als einfache
¨
Prozess-Referenzmodelle betrachtet werden. Uber
die im Standard angewendete unmittelbare
Zuordnung von Nachrichtentypen zu Ereignistypen wird eine Verkn¨
upfung zwischen der anwendungssystemunabh¨
angigen Prozessbetrachtung und der Betrachtung der Kommunikation
von Anwendungssystemen hergestellt.
Ereignistypen im 3LGM2
In Abschnitt 6.4 wurden kurz die M¨
oglichkeiten der Modellierung von Informations- und Kommunkationsprozessen auf der Basis des 3LGM2 beschrieben. Bisher wurden Ereignistypen
auf der logischen Werkzeugebene des 3LGM2 modelliert und konnten u
¨ ber die Assoziationsbeziehung wird_ausgel¨
ost_durch_eine_Aktivit¨
at_der Aufgaben zugeordnet werden. Dabei
konnte nicht unmittelbar beschrieben werden, ob der Ereignistyp in Zusammenhang mit
dem Zugriff auf alle mit der betreffenden Aufgabe assoziierten Objekttypen steht oder nur
¨
mit dem Zugriff auf eine bestimmte Teilmenge dieser Objekttypen. Uber
die Assoziation mit
Nachrichten- und Dokumententypen, die wiederum mit Objekttypen asoziiert sind, konnten die Beziehungen zu Objekttypen mittelbar hergestellt werden. Dieser Umweg“ entspricht
”
jedoch nicht der Bedeutung von Ereignistypen f¨
ur die fachliche Ebene.
Die fachliche Ebene des 3LGM2 wird hier durch das Verschieben“ der Klasse Ereignistyp
”
und die Erg¨
anzung von Assoziationsbeziehungen zur greift_zu_auf-Beziehung u
¨ berarbeitet
(Abbildung 7.1).
Die Assoziationsbeziehungen l¨
ost_aus und wird_ausgel¨
ost_durch sind unmittelbar f¨
ur
die Integration von Anwendungsbausteinen von Bedeutung:
1. L¨
ost ein Ereignistyp einen Zugriff auf Objekttypen aus, wird also eine Aktivit¨
at einer Aufgabe ausgel¨
ost, dann muss die zugeh¨
orige Funktionalit¨
at entweder unmittelbar
100
¨
7.2 Uberarbeitung
des 3LGM2
ist_äquivalent_zu
0..*
0..*
Ereignistyp
löst_aus
0..*
0..*
wird_ausgelöst_durch
1..*
1..*
Rolle
greift_zu_auf
0..*
erledigt
Zugriffsart: {interpretierend,
bearbeitend}
ist_Teil_von
ist_Teil_von
0..*
0..*
Objekttyp
0..*
0..*
0..*
0..*
Aufgabe
greift_zu_auf
0..*
0..*
ist_Teil_von
0..*
0..*
wird_erledigt_in
0..*
Organisationseinheit
Abbildung 7.1: Fachliche Ebene des 3LGM2A ; hervorgehoben sind die u
¨berarbeiteten Klassen.
in den unters¨
utzenden Anwendungsbausteinen implementiert sein, oder diese m¨
ussen
die Funktionalit¨
at u
¨ ber Kommunikation mit einem anderen Anwendungsbaustein erwerben. Letzteres gilt sehr oft f¨
ur die Funktionalit¨
at zur Unterst¨
utzung bestimmter
Teil-Aufgaben, die zu mehreren u
oren und deutet auf die
¨ bergeordneten Aufgaben geh¨
Nutzung spezialisierter Komponenten und die Forderung nach funktionaler Integration
hin (siehe Abschnitte 9.3.2).
2. Wird ein Ereignistyp durch bearbeitenden Zugriff auf Objekttypen ausgel¨
ost, hat also
eine bearbeitende Aktivit¨
at einer Aufgabe stattgefunden, dann muss die damit verbunde¨
ne Anderung
von Daten ggf. an andere Anwendungsbausteine, welche interpretierende1
Aufgaben unterst¨
utzen, weitergegeben werden. Das gilt sehr oft f¨
ur Objekttypen, die
bei der Erf¨
ullung vieler unterschiedlicher Aufgaben interpretiert werden und deutet auf
die Forderung nach Datenintegration hin (siehe Abschnitt 9.3.1).
¨
alt auch die AssoziationsDie Uberarbeitung
des 3LGM2 hinsichtlich der Ereignistypen enth¨
beziehung ist_¨
aquivalent_zu f¨
ur Ereignistypen. Damit k¨
onnen beispielsweise Ereignistypen aus verschiedenen Kommunikationsstandards mit gleicher Bedeutung verkn¨
upft werden. Tabelle 7.1 zeigt Beispiele f¨
ur ¨
aquivalente Ereignistypen der Kommunikationsstandards
HL7 und SAP-HCM. Die Tabelle l¨
asst auch erkennen, warum eine transitive Auswertung der
¨
hier definierten Aquivalenzbeziehung
nicht sinnvoll ist: Beispielsweise werden die im Kommunikationsstandard SAP-HCM definierten Ereignistypen NP11I0 und NP11P0 im Kommunikationsstandard HL7 u
uckt. NP11I0 und NP11P0 sind
¨ ber den Ereignistyp A01 ausgedr¨
jedoch nicht ¨
aquivalent. In HL7 wird die entsprechende Unterscheidung durch zus¨
atzliche Angaben innerhalb der u
ur
¨ bermittelten Nachrichten erreicht. Sofern eine Unterscheidung auch f¨
HL7-Nachrichten erforderlich ist, kann sie mit dem 3LGM2 nur u
¨ ber Modellierung eigener“
”
auf A01 basierender Ereignistypen erreicht werden.
1
Hier wird das Attribut Zugriffsart der greift_zu_auf-Beziehung zwischen den Klassen Aufgabe und Objekttyp verwendet.
101
¨
7 Flexible Architekturmodellierung — Uberarbeitung
des 3LGM2
A01
HL7-Ereignistyp
(admit / visit notification)
A02
(transfer a patient)
A03
(discharge/end visit)
A08
(update patient information)
A11
A12
A13
(cancel admit / visit notification)
(cancel transfer)
(cancel discharge / end visit)
NP11I0
NP11P0
NV11I0
NV11P0
NP97I0
NP97P0
NP12I0
NV12I0
NP98I0
NP12IS
NV12IS
NP98IS
HCM-Ereignistyp
(Aufnahme anlegen (Ist)),
(Aufnahme anlegen (Plan))
(Verlegung anlegen (Ist)),
(Verlegung anlegen (Plan))
(Entlassung anlegen (Ist)),
(Entlassung anlegen (Plan))
(Aufnahme ¨
andern),
(Verlegung ¨
andern),
(Entlassung ¨
andern)
(Aufnahme stornieren)
(Verlegung stornieren)
(Entlassung stornieren)
Tabelle 7.1: Beispiele f¨
ur ¨
aquivalente Ereignistypen in den Kommunikationsstandards HL7 und SAP-HCM (vgl. Tabelle 6.1; Quellen: [HL7 1999] und [SAP 2005])
7.2.2 Schnittstellen und Operationen
atzlich den in den AbschnitDie Klasse Bausteinschnittstelle im 3LGM2 entspricht grunds¨
ten 4.2.2 und 4.2.3 zitierten Definitionen f¨
ur Schnittstelle (interface). Die unmittelbaren Assoziationsbeziehngen zu den Klassen Ereignistyp-Nachrichtentyp und Ereignistyp-Dokumententyp (vgl. Abildung 6.2a) und die weiterf¨
uhrenden Assoziationsbeziehungen zu Nachrichtentyp, Dokumententyp und Ereignistyp betonen den Ansatz der nachrichtenbasierten Kommunikation zwischen Komponenten und die daf¨
ur entwickelten Technologien, z. B.
Kommunikationsserver (vgl. Abschnitt 4.4.3). Damit ist beispielsweise eine Architekturmodellierung, die die Anforderung und Nutzung von Diensten in den Vordergrund stellt (vgl.
Abschnitte 4.2.1, 4.2.3 und 4.2.5), nicht bzw. nur eingeschr¨
ankt m¨
oglich. Gleiches gilt auch f¨
ur
Architekturen, die den in Abschnitt 4.4.3 vorgestellten EAI-Architekturmustern entsprechen,
mit Ausnahme des Musters Integrationsbote.
Operationen als flexible Elemente zur Kommunikationsmodellierung
Mit den bisherigen Klassen und Assoziationsbeziehungen des 3LGM2 ist es also nicht bzw. nur
schwer m¨
oglich, eine u
¨ ber den einfachen Nachrichten- bzw. Dokumentenaustausch hinausgehende Interaktion zu modellieren. Insbesondere kann der Zusammenhang zwischen den m¨
oglicherweise bei einer Interaktion initial u
uckgegebenen
¨ bergebenen Daten und den als Antwort zur¨
Daten nicht modelliert werden. Diese Tatsache f¨
uhrt zur Forderung der Ber¨
ucksichtigung des
Begriffes Operation.
In dieser Arbeit wird angenommen, dass jede Art der Interaktion von Komponenten u
¨ ber
Operationen im Sinne des im OMG Object Model definierten Operationsbegriffes beschrieben
werden kann (vgl. die zitierte Definition und Erkl¨
arung f¨
ur Operation in Abschnitt 4.2.3). Die
Annahme wird im Zusammenhang mit der Annahme getroffen, dass die Anforderungen bzgl.
detaillierter Kommunikationsmodellierung aus Sicht des Managements von Informationssystemen geringer sind als aus Sicht der Softwareentwicklung.
In vielen F¨
allen wird die Interaktion von Komponenten u
¨ ber eine Sequenz von aufeinanderfolgenden Operationsaufrufen modelliert werden m¨
ussen2 .
2
Vgl. dazu die Definition f¨
ur Aktivit¨
at als Graph von Aktionen im RM-ODP ([ISO/IEC JTC 1 1996b], S. 4,
Definition 8.5).
102
¨
7.2 Uberarbeitung
des 3LGM2
0:.*
Objekttyp
0:.*
wird_gespeichert_von
0..*
Dokumententyp
0..*
0..*
0..*
Customizing: Text
0..*
papierbasierter
Anwendungsbaustein
0:.*
0..*
verwaltet_Daten_mit
basiert_auf
1
basiert_auf
0..1
Datenbankverwaltungssystem
Softwareprodukt
Standardorganisationsplan (SOP)
0..*
0..*
Organisationsplan: Text
0..*
0..*
ist_Teil_von
0:.*
Nachrichtentyp
0..*
0..*
0..*
besitzt
wird_erledigt_in
Organisationseinheit
mit_Hilfe_von
Bausteinschnittstelle
Nachrichtentyp /
Dokumenttyp
Benutzungsschnittstelle
wird_
erledigt_in
0..*
0..*
0..*
Kommunikationsschnittstelle
0..1
kann_aufrufen
0..* Aufgabe
Anwendungsbaustein
1
0..*
mit_Hilfe_von
0..*
greift_zu_auf
0..1
stellt_bereit
Zugr-art: {interpretierend,
bearbeitend}
stellt_bereit
0..*
0..*
Kommunikationsbeziehung
kann_aufrufen
hat_Parametertyp
hat_Ergebnistyp
0..*
0..*
0..*
0..*
0..*
Operation
Synchronitätsmodus: {synchron, asynchron}
wird_vermittelt_über
Transakt.-modus:
{Commit erforderlich,
Commit nicht erford.}
1
1
0..*
wird_aktiv_bei
löst_aus
0..*
wird_ausgelöst_von
0..*
kann_unterstützen
0..*
rechnerbasierter
Anwendungsbaustein
kann_unterstützen
0..*
hat_als_Master
wird_transportiert_über
wird_gespeichert_von
0..*
Ereignistyp
0..*
uhrte Klasse Operation und
Abbildung 7.2: Logische Werkzeugebene des 3LGM2A ; hervorgehoben sind die neu eingef¨
die u
¨berarbeiteten Assoziationsbeziehungen.
Operationen im 3LGM2
Auf der Basis der Ausf¨
uhrungen zum Begriff Operation wird hier die Klasse Operation auf der
logischen Werkzeugebene in das 3LGM2A eingef¨
uhrt. Mit der Einf¨
uhrung werden auch die Assoziationsbeziehungen der Klassen Bausteinschnittstelle und Ereignis-Nachrichtentyp/Ereignis-Dokumententyp u
¨ berarbeitet, insbesondere die Beziehung Kommunikationsbeziehung.
Die Modellierung von Kommunikation ist infolge dessen nur noch u
¨ ber das Modellieren von
Operationen und Operationsaufrufen m¨
oglich (Abbildung 7.2).
Den von einem Anwendungsbaustein zur Verf¨
ugung gestellten Operationen k¨
onnen Parameter- und Ergebnistypen zugeordnet werden. Diese k¨
onnen mit den bereits im 3LGM2 definierten
Klassen Nachrichtentyp und Dokumententyp modelliert werden.
Eine Kommunikationsbeziehung zwischen zwei Bausteinschnittstellen ist nur dann m¨
oglich, wenn eine der beiden eine bestimmte Operation bereitstellt, die von der anderen aufgerufen werden kann. Aus diesem Grund ist die Kommunikationsbeziehung im u
¨ berarbeiteten
2
3LGM eine Assoziationsbeziehung zwischen den beiden Assoziationsklassen stellt_bereit
und kann_aufrufen.
F¨
ur die Verwendung in den Kapiteln zur Architekturbewertung werden hier, analog zu den
Mengendefinitionen in Kapitel 6, semiformale Mengendefinitionen angegeben:
103
¨
7 Flexible Architekturmodellierung — Uberarbeitung
des 3LGM2
Kasten 7.1: Das Weglassen der Konfigurationen im 3LGM2A
Im 3LGM2 sind f¨
ur die Verkn¨
upfung von Aufgaben mit Anwendungsbausteinen und f¨
ur die Verkn¨
upfung von Anwendungsbausteinen mit physischen Datenverarbeitungsbausteinen Konfigurationsklassen vorgesehen. Diese wurden
im 3LGM2A weggelassen, um Modellierer zu mehr Ausf¨
uhrlichkeit und Pr¨
azision bei der 3LGM2A -basierten Modellierung
zu zwingen“.
”
Wird beispielsweise eine Aufgabe mit einer Anwendungsbausteinkonfiguration mit mehr als einem Anwendungsbaustein verkn¨
upft, dann wird dabei nicht ausgedr¨
uckt, wof¨
ur die einzelnen Anwendungsbausteine tats¨
achlich bei der
Erledigung der betreffenden Aufgabe verwendet werden. Damit werden Analysen wie die in Kapitel 9 beschriebenen
¨
Uberpr¨
ufungen der Erf¨
ullung von Integrationsanforderungen erschwert. Es kann u. a. nicht unterschieden werden, ob
die Anwendungsbausteine jeweils alle der von der betreffenden Aufgabe zugegriffenen Objekttypen ben¨
otigen oder nur
einzelne.
OP
:=
{x | x ist eine Operation.}
(7.1)
SB
:=
{x | x ist eine stellt_bereit-Beziehung.}
(7.2)
KA
:=
{x | x ist eine kann_aufrufen-Beziehung.}
(7.3)
Die Bedeutung des Mengenk¨
urzels KOMB f¨
ur Kommunikationsbeziehungen ¨
andert sich im
Vergleich zu der aus Abschnitt 6.3.2, da die neuen“ Kommunikationsbeziehungen in einem
”
3LGM2A -basierten Modell Beziehungen zwischen stellt_bereit-Beziehungen und kann_aufrufen-Beziehungen sind.
Attribute f¨
ur die qualitative Beschreibung der Kommunikation
Die eingef¨
uhrte Klasse Operation hat das Attribut Synchronit¨
atsmodus mit den m¨oglichen
Werten synchron und asynchron. Es wird in Abschnitt 10.3 zur Bewertung von Abh¨
angigkeiten von Anwendungsbausteinen verwendet. Aufrufe von synchronen Operationen blockieren
den aufrufenden Anwendungsbaustein solange, bis die Operation ausgef¨
uhrt und das evtl.
zugeh¨
orige Ergebnis tats¨
achlich zur¨
uckgegeben wurde. Aufrufe von asynchronen Operationen blockieren den aurufenden Anwendungsbaustein nicht. Diese einfache Modellierung der
ur den ausf¨
uhrlichen
(A)Synchronit¨
at u
¨ ber ein Attribut wird angewendet, da das 3LGM2 nicht f¨
Softwareentwurf entwickelt wurde. Bei der Implementierung asynchroner Kommunikation mit
Ergebnisr¨
uckgaben sind i. d. R. mindestens zwei Aufrufe von Funktionen bzw. Prozeduren not¨
wendig: ein Aufruf f¨
ur die Ubermittlung
der Anfrage und ein Aufruf f¨
ur die R¨
uck¨
ubermittlung
3
des Ergebnisses .
Bei der u
¨ berarbeiteten Assoziationsklasse Kommunikationsbeziehung wurde das Attribut
Transaktionsmodus mit den m¨
oglichen Werten Commit erforderlich und Commit nicht erforderlich erg¨
anzt. Wie das Attribut Synchronit¨
atsmodus der Klasse Operation wird es in
Abschnitt 10.3 zur Bewertung der Abh¨
angigkeit von Anwendungsbausteinen verwendet. Ein
Commit wird hier in Anlehnung an den Commit-Begriff in der Datenbanktheorie (siehe z. B.
[Vossen 2000], S. 582-596 oder [Rahm 1994], S. 111-131) vereinfacht als das Best¨
atigen des Erfolges eines Operationsaufrufes aufgefasst: Bei einer Kommunikationsbeziehung, die ein Commit erfordert, wird die Transaktion im aufrufenden Anwendungsbaustein, die zum Operationsaufruf f¨
uhrte, zur¨
uckgenommen, wenn das Commit nicht geliefert wird.
3
Die Anfrage muss nicht notwendigerweise eine echte“ Anfrage nach bestimmten anwendungsbezogenen Da”
ten, z. B. Patientendaten, sein. Sie kann beispielsweise auch eine Aufforderung zur Speicherung bzw. Weiterverarbeitung bestimmter Daten sein, wobei der Erfolg der Speicherung bzw. Weiterverarbeitung u
¨ ber eine
Statusnachricht zur¨
uck¨
ubermittelt wird.
104
7.3 Transformation von Nachrichtentypen
Operationen und die fachliche Ebene des 3LGM2A
Die Klasse Operation hat zwei unmittelbare Assoziationsbeziehungen zu Klassen der fachlichen
Ebene.
Die Beziehung wird_aktiv_bei zur Klasse Ereignistyp repr¨
asentiert den Zusammenhang
zwischen der Modellierung von Informationsprozessen auf der fachlichen Ebene und von
Kommunikationsprozessen auf der logischen Werkzeugebene (vgl. Abschnitt 6.4). Abh¨
angig
vom Eintreten bestimmter fachlicher Ereignisse m¨
ussen im betrachteten Informationssystem
u. U. Kommunikationsbeziehungen aktiv werden. Dadurch werden dann den Anwendungsbausteinen die die betreffenden Aufgaben unterst¨
utzen, relevante Daten u
o¨ bermittelt oder ben¨
tigte Funktionalit¨
at bereitgestellt.
Mit der Beziehung mit_Hilfe_von zwischen der Assoziationsklasse wird_erldigt_in und
der Klasse Operation kann modelliert werden, welche Funktionalit¨
at durch Operationen bereitgestellt wird. Bei sehr dataillierter Betrachtung der Funktionalit¨
atsbereitstellung ist eine
entsprechend detaillierte Modellierung von Aufgaben erforderlich. Wenn z. B. die Bereitstellung von Funktionalit¨
at zur Suche bestimmter Informationen betrachtet werden soll, muss eine
zugeh¨
orige Aufgabe modelliert worden sein.
¨
Uber Operationen und Kommunikationsbeziehungen wird die Bereitstellung von Funktionalit¨
at von Anwendungsbausteinen f¨
ur andere Anwendungsbausteine und die Nutzung der
Funktionalit¨
at modelliert. Die Bereitstellung von Funktionalit¨
at von Anwendungsbausteinen
f¨
ur ihre Benutzer wird durch die Assoziationsbeziehung mit_Hilfe_von zwischen der Assoziationsklasse wird_erldigt_in und der Klasse Benutzungsschnittstelle modelliert. Auf eine
detailliertere Modellierung der Benutzungsschnittstellen wie bei den Bausteinschnittstellen wird hier verzichtet.
7.3 Transformation von Nachrichtentypen
In vielen Informationssystemen werden bei der Daten¨
ubermittlung Nachrichten bestimmter
Nachrichtentypen in Nachrichten anderer Nachrichtentypen transformiert4 . Sehr oft erfolgt
dabei auch eine Umbenennung des der betreffenden Nachricht zugeordneten Ereignistyps.
Das geschieht vor allem bei Anwendung unterschiedlicher Kommunikationsstandards, da
unterschiedliche Kommunikationsstandards gleiche oder ¨
ahnliche Nachrichtentypen oft unterschiedlich benennen.
Das Transformieren von Nachrichtentypen kann u
¨ ber Kommunikationsbeziehungen modelliert werden, bei denen die aufrufende Bausteinschnittstelle gleichzeitig die bereitstellende
Bausteinschnittstelle ist. Dabei ist der Quell-Nachrichtentyp der aufgerufenen Operation
als Parametertyp zugeordnet, der Ziel-Nachrichtentyp folglich als Ergebnistyp.
7.4 Dienste
7.4.1 Spezifikationen f¨
ur Dienste
Informationale und funktionale Spezifikationen f¨
ur Informationssystemkomponenten legen oft
nicht ausdr¨
ucklich fest, ob sie durch eine einzige Komponente oder eine Kombination mehrerer
4
Im Folgenden wird kurz Transformation von Nachrichtentypen“ o. ¨
a. geschrieben.
”
105
¨
7 Flexible Architekturmodellierung — Uberarbeitung
des 3LGM2
Komponenten zu erf¨
ullen sind. Daher wird in diesem Zusammenhang von Diensten (bzw.
Spezifikationen von Diensten), nicht von Komponenten, gesprochen.
Definition 7.1 Ein Dienst stellt bestimmte Funktionalit¨
aten zur Informationsverarbeitung
zur Verf¨
ugung. Er kann durch einen oder mehrere Komponenten realisiert sein.
Ende — Definition
Dienstspezifikationen k¨
onnen nach zwei Dienstkategorien unterschieden werden: Anwendungsdienste und Vermittlungsdienste. Spezifikationen f¨
ur Anwendungsdienste beinhalten u. a.
– Informationen, die in einem oder mehreren Anwendungsbereichen verarbeitet werden,
z. B. Fallinformationen oder Befundinformationen,
– Funktionalit¨
aten zur Verarbeitung der Informationen, z. B. Operationen5 zur Befundpr¨
asentation,
– Strukturen zum Austausch der Informationen, z. B. Nachrichtentypen f¨
ur die Befundu
¨ bermittlung, und
– Ereignistypen, die das Aktivieren/Abfragen von Funktionalit¨
aten ausl¨
osen, z. B. einen
Ereignistyp der das Vorliegen von Befunden ausdr¨
uckt.
Diese vier Teilspezifikationen k¨
onnen unterschiedlich stark ausgepr¨
agt sein. Spezifikationen f¨
ur
Anwendungsdienste sind u. a. im HL7-Kommunikationsstandard6 , in anwendungsbereichspezifischen Dienstspezifikationen zur OMA und in der HISA enthalten. Beispiele f¨
ur Anwendungsdienste sind der Person Identification Service (PIDS) aus den OMA-Diensten f¨
ur das
Gesundheitswesen oder der Subject of Care Healthcare Common Services (S-HCS) der HISA.
Spezifikationen f¨
ur Vermittlungsdienste beinhalten u. a.
– Informationen, die zur Vermittlung von Diensten ben¨
otigt werden, z. B. Adressen von
Dienstimplementierungen oder Verschl¨
usselungsmethoden,
– Funktionalit¨
aten f¨
ur die Vermittlung von Kommunikationsverbindungen zum Aufruf von
Diensten, z. B. Operationen zur Lokalisierung von Dienstimplementierungen,
– Strukturen zum Austausch vermittlungsspezifischer Informationen, z. B. Nachrichtentypen f¨
ur das Registrieren von Dienstimplementierungen in einem daf¨
ur vorgesehenen
Verzeichnis oder das Abfragen der Lokalisation von Dienstimplementierungen aus diesem Verzeichnis, und
– Ereignistypen, die das Aktivieren/Abfragen einer vermittlungsspezifischen Funktionalit¨
at
ausl¨
osen, z. B. einen Ereignistyp, der das Bereitstehen einer neuen Dienstimplementierung
ausdr¨
uckt.
Zu diesen Spezifikationen geh¨
oren u. a. der CORBA-Standard und das DCOM.
5
6
In der Beschreibung der Dienstspezifikationen sind un¨
achst keine Begriffe aus dem 3LGM2 gemeint. Deshalb
2
erfolgt keine Anwendung der Schriftart f¨
ur 3LGM -Klassen.
Im HL7-Kommunikationsstandard wird nicht ausdr¨
ucklich von Diensten gesprochen, jedoch enth¨
alt er Spezifikationen f¨
ur Anwendungsdienste in der in dieser Arbeit unterstellten Bedeutung.
106
7.5 Kommunikationsverbindungen
7.4.2 Modellierung von Diensten mit dem 3LGM2
Anwendungsdienste
Zur Beschreibung von Anwendungsdiensten (vgl. 7.4.1) stellt das u
¨ berarbeitete 3LGM2 folgende Klassen zur Verf¨
ugung:
– Objekttyp auf der fachlichen Ebene zur Beschreibung der anwendungsspezifischen Informationen,
– Aufgabe auf der fachlichen Ebene als inhaltliche Vorgabe f¨
ur die bereitzustellende Funktionalit¨
at,
– Nachrichtentyp auf der logischen Werkzeugebene zur Beschreibung von Strukturen zum
Informationsaustausch u
¨ ber Bausteinschnittstellen beim Eintreten von bestimmten
Ereignistypen und
– Anwendungsbaustein, Operation und Nachrichtentyp auf der logischen Werkzeugebene
zur Beschreibung der Bereitstellung von implementierter Funktionalit¨
at durch Komponenten f¨
ur andere Komponenten.
Vermittlungsdienste
Zur Beschreibung von Vermittlungsdiensten (vgl. 7.4.1) stellt das 3LGM2 auf der logischen
Werkzeugebene dieselben Klassen wie f¨
ur die Modellierung von Anwendungsdiensten zur Verf¨
ugung. Zus¨
atzlich wird
– die Assoziationsbeziehung vermittelt zur Beschreibung der Tatsache, dass eine Kommunikationsbeziehung durch eine oder mehrere andere Kommunikationsbeziehungen
vermittelt wird,
zur Verf¨
ugung gestellt.
7.5 Kommunikationsverbindungen
¨
Bei der Ubertragung
von Informationen werden Daten oft von einem Start-Anwendungsbaustein u
¨ ber mehrere Anwendungsbausteine hinweg zu einem Ziel-Anwendungsbaustein u
¨ bermittelt.
F¨
ur die Modellierung der direkten Kommunikation zweier Anwendungsbausteine sieht das
¨
3LGM2 bereits die Assoziationsklasse Kommunikationsbeziehung vor. Uber
den Begriff Kommunikationsverbindung wird die Kommunikation zwischen Anwendungsbausteinen auf eine
Folge von Kommunikationsbeziehungen verallgemeinert. Dabei wird die Assoziationsbeziehung wird_vermittelt_¨
uber im 3LGM2 ber¨
ucksichtigt (Abbildung 7.2).
Definition 7.2 Eine Kommunikationsverbindung ist eine Folge von Kommunikationsbeziehungen. Dabei gilt f¨
ur jede Kommunikationsbeziehung, mit Ausnahme der letzten,
– dass sie die nach ihr stehende Kommunikationsbeziehung vermittelt,
– dass sie gemeinsam mit einer oder mehreren nach ihr stehenden Kommunkationsbeziehungen die danach stehende Kommunikationsbeziehung vermittelt oder
– dass ihre anbietende Bausteinschnittstelle aufrufende Bausteinschnittstelle einer
folgenden Kommunikationsbeziehung ist.
107
¨
7 Flexible Architekturmodellierung — Uberarbeitung
des 3LGM2
¨
Abbildung 7.3: Eine Kommunikationsverbindung zur Ubertragung
von Falldaten im Informationssystem des UKL
Ende — Definition
Die Abbildungen 7.3 und 7.6 zeigen Beispiele f¨
ur Kommunikationsverbindungen ohne vermittelnde Kommunikationsbeziehungen. Abbildung 7.5 zeigt ein Beispiel f¨
ur Kommunikationsverbindungen mit vermittelnden Kommunikationsbeziehungen.
7.6 Beispiele f¨
ur die Modellierung verschiedener Architekturstile
Die in diesem Abschnitt beschriebenen Beispiele sind auf die Architekturmodellierung mit Hilfe
der Klassen der logischen Werkzeugebene bezogen. Die Anwendung der in Abschnitt 7.2.1
¨
beschriebenen Uberarbeitung
der fachlichen Ebene erfolgt in Kapitel 9.
7.6.1 Modellierung von HISA-basierten Architekturen
Informationssystemkomponenten, die den Vorgaben des HISA-Standards EN 12967-1 (vgl.
Abschnitt 4.2.4) entsprechen, k¨
onnen auf der Basis des 3LGM2 folgendermaßen modelliert
werden:
108
7.6 Beispiele f¨
ur die Modellierung verschiedener Architekturstile
Abbildung 7.4: Eine einfache OMA-basierte Architektur
1. Informationsklassen werden auf Objekttypen abgebildet. Den Objekttypen werden Nachrichtentypen als Parametertypen und Ergebnistypen f¨
ur die Dienstoperationen zugeordnet.
2. Informationssystemkomponenten, die die Funktionalit¨
atsbeschreibung implementieren,
werden auf Anwendungsbausteine abgebildet.
3. Elemente der Funktionalit¨
atsbeschreibungen werden auf Operationen abgebildet.
Beispiel
Ein einfaches Modell einer Implementierung von Diensten der Gruppe Subjects of Care Heal”
thcare Common Services (S-HCS)“ k¨
onnte, abh¨
angig von der Implementierung, u. a. folgende
Elemente enthalten (Abbildung 7.4):
– die Objekttypen Patient und Fall (vgl. [CEN TC251 1997], S. 15-18),
– einen Anwendungsbaustein S-HCS-Modul mit einer Bausteinschnittstelle, der die
Operationen Find patient by name, Find patient by patient ID, Find case by case ID und
Find case by patient ID zugeordnet sind, und einer weiteren Bausteinschnittstelle,
der die Operationen Register patient, Update patient data, Register case und Update case
data zugeordnet sind (vgl. [CEN TC251 1997], S. 39),
– die Nachrichtentypen Patient query message, Patient query result message und Patient
admittance message, die den Operationen als Parameter bzw. Ergebnistypen zugeordnet
sind,
– die Anwendungsbausteine Patientenverwaltungssystem, Laborinformationssystem und
Pathologieinformationssystem, die die S-HCS nutzen,
109
¨
7 Flexible Architekturmodellierung — Uberarbeitung
des 3LGM2
– je eine Bausteinschnittstelle f¨
ur die letztgenannten Anwendungsbausteine, u
¨ ber die
sie die Operationen zur Abfrage von Patienten- und Falldaten der S-HCS aufrufen, und
– ein Bausteinschnittstelle f¨
ur das Patientenverwaltungssystem Anwendungsbausteine, u
¨ ber die es die Operationen zur Registrierung (Speicherung) von Patienten- und
Falldaten der S-HCS aufruft.
Eine vollst¨
andiges Modell einer Implementierung der Dienstgruppe m¨
usste um weitere Elemente erg¨
anzt werden.
7.6.2 Modellierung von OMA-basierten Architekturen
Komponenten eines OMA-basierten Informationssystems k¨
onnen auf der Basis des 3LGM2
folgendermaßen modelliert werden:
1. Ein ORB wird auf einen Anwendungsbaustein abgebildet.
2. Die vom ORB und den anderen Komponenten bereitgestellten Operationen werden auf
3LGM2 -Operationen abgebildet.
3. Definitionen f¨
ur die Parametertypen und die Ergebnisstypen der Operationen werden auf
Nachrichtentypen abgebildet.
Da sowohl die OMA als auch die CORBA, die Spezifikation f¨
ur die zentrale Komponente der
OMA, keine anwendungsbezogenen Informations- oder Funktionalit¨
atsbeschreibungen enthalten, k¨
onnen zun¨
achst keine Bez¨
uge zur fachlichen Ebene des 3LGM2 hergestellt werden. Wenn
spezielle Dienstspezifikationen der OMG, z. B. die Spezifikation des Person Identification Service, angewendet werden, k¨
onnen die enthaltenen Datentypen in einem 3LGM2 -Modell als
Nachrichtentypen mit Objekttypen in Beziehung gesetzt werden. Die speziellen Operationen k¨
onnen mit Aufgaben in Beziehung gesetzt werden.
Beispiel
Ein einfaches Modell einer Implementierung von Diensten zur Patientenverwaltung in einer
OMA-basierten Architektur k¨
onnte u. a. folgende Elemente enthalten (Abbildung 7.5):
– die Objekttypen Patient und Fall,
– einen Anwendungsbaustein PIDS-Modul (PIDS=Patient Identification Service) mit einer
Bausteinschnittstelle, der die Operationen find or register ids und find candidates
zugeordnet sind (vgl. [OMG 2001c], S. 2-28 - 2-32 und 2-19 - 2-21),
– die Nachrichtentypen entsprechend der PIDS-Spezifikation, die den Operationen des
PIDS als Parameter bzw. Ergebnistypen zugeordnet sind,
– einen Anwendungsbaustein TOS-Modul (TOS=Trading Object Service) mit einer Bausteinschnittstelle, der die Operationen export und query zugeordnet sind (vgl. [OMG
2000f], S. 2-9 - 2-17 und 2-3 - 2-8),
– die Nachrichtentypen entsprechend der TOS-Spezifikation, die den Operationen des
TOS als Parameter bzw. Ergebnistypen zugeordnet sind,
– einen Anwendungsbaustein ORB mit Bausteinschnittstellen, die den IDL Stubs und
den Skeletons f¨
ur die beteiligten Komponenten entsprechen,
110
7.6 Beispiele f¨
ur die Modellierung verschiedener Architekturstile
Abbildung 7.5: Eine einfache OMA-basierte Architektur
– die Anwendungsbausteine Patientenverwaltungssystem, Laborinformationssystem und
Pathologieinformationssystem, die den TOS und den PIDS nutzen,
– je eine Bausteinschnittstelle f¨
ur die letztgenannten Anwendungsbausteine, u
¨ ber die
sie die Operationen des TOS aufrufen, und
– je eine Bausteinschnittstelle f¨
ur die letztgenannten Anwendungsbausteine, u
¨ ber die
sie die Operationen des PIDS aufrufen.
7.6.3 Modellierung von Kommunikationsserver-basierten Architekturen
Komponenten eines Kommunikationsserver-basierten Informationssystems k¨
onnen auf der Ba2
sis des 3LGM folgendermaßen modelliert werden:
1. Ein Kommunikationsserver wird auf einen Anwendungsbaustein abgebildet.
2. Schnittstellenmodule werden auf Bausteinschnittstellen abgebildet.
3. Nachrichtenstrukturdefinitionen werden auf Nachrichtentypen abgebildet.
4. Routendefinitionen f¨
ur die Weitergabe von Nachrichten zwischen den Bausteinschnittstellen des Kommunikationsservers werden auf Kommunikationsbeziehungen von Bausteinschnittstellen innerhalb des entsprechenden Anwendungsbausteines abgebildet.
Da das Kommunikationsserverkonzept nicht auf bestimmte Unternehmensaufgaben oder Informationen beschr¨ankt ist, k¨
onnen keine Bez¨
uge zur fachlichen Ebene hergestellt werden7 .
7
Mit einigen Kommunikationsserverprodukten werden anwendungsspezifische Nachrichtenstrukturdefinitionen,
¨
z. B. f¨
ur HL7-Nachrichten, zur Verwendung in Filter- und Ubersetzungsdefinitionen
mitgeliefert. Trotzdem
111
¨
7 Flexible Architekturmodellierung — Uberarbeitung
des 3LGM2
Abbildung 7.6: Eine einfache Kommunikationsserverarchitektur
Beispiel
Ein einfaches Modell einer Implementierung von Komponenten zur Patientenverwaltung in
einer Kommunikationsserver-basierten Architektur k¨
onnte u. a. folgende Elemente enthalten
(Abbidung 7.6; vgl. [HL7 1999], Kapitel 3):
– die Objekttypen Patient und Fall,
– einen Anwendungsbaustein Kommunikationsserver,
– eine Bausteinschnittstelle des Kommunikationsservers, die die Operation receive mit
dem Nachrichtentyp ADT als Parametertyp bereitstellt und die die gleiche Operation
mit dem Nachrichtentyp ACK als Parameter aufrufen kann,
– zwei Bausteinschnittstellen des Kommunikationsservers, die jeweils die Operation
receive mit dem Nachrichtentyp ADT als Parametertyp aufrufen k¨
onnen und die die
gleiche Operation mit dem Nachrichtentyp ACK als Parameter bereitstellen,
– einen Anwendungsbaustein Patientenverwaltungssystem mit einer Bausteinschnittstelle, die die Operation Receive mit dem Nachrichtentyp ADT als Parametertyp
aufrufen kann und die die gleiche Operation mit dem Nachrichtentyp ACK als Parameter bereitstellt, und
– die Anwendungsbausteine Laborinformationssystem und Pathologieinformationssystem
mit je einer Bausteinschnittstelle, die die Operation Receive mit dem Nachrichtentyp ADT als Parametertyp bereitstellt und die die gleiche Operation mit dem Nachrichtentyp ACK als Parameter aufrufen kann.
sind auch diese Produkte nicht auf einen bestimmten Anwendungsbereich beschr¨
ankt.
112
7.7 Einf¨
uhrung der Klasse Begriffssystem
7.7 Einf¨
uhrung der Klasse Begriffssystem
Unabh¨
angig von der Modellierung verschiedener Architekturstile wird in diesem Abschnitt zur
Modellierung der semantischen Integration (vgl. Abschnitt 2.2.4) erg¨
anzend eine weitere Klasse
uhrt: die Klasse Begriffssystem (Abbildung 7.7).
auf der fachlichen Ebene des 3LGM2A eingef¨
BGS
:=
{bgs | bgs ist ein Begriffssystem.}
(7.4)
Wenn eine Aufgabe auf einen Objekttyp zugreift, dann kann u
¨ ber die in das 3LGM2A eingef¨
uhrte Assoziationsbeziehung unter_Ber¨
ucksichtigung_von zus¨
atzlich ausgedr¨
uckt werden,
dass dabei ein bestimmtes Begriffssystem ber¨
ucksichtigt wird. Ein Beispiel ist die Ber¨
ucksichtigung des ICD10-Diagnosenkataloges bei der Diagnosendokumentation (Abbildung 7.8).
Der Nutzen der Modellierung von Begriffssystemen liegt u. a. darin, dass
– dokumentiert wird, welche Begriffssysteme verwendet werden,
– abgeleitet werden kann, in welchen Anwendungsbausteinen welche Begriffssysteme
ben¨
otigt werden, und
– abgeleitet werden kann, in welchen Anwendungsbausteinen welche Begriffssysteme
gespeichert sind und wie sie ggf. zwischen Anwendungsbausteinen ausgetauscht werden.
Alle dieser Argumente charakterisieren die Thematik der semantischen Integration aus der Sicht
des Managements von Informationssystemen. Die Bestimmung von entsprechenden Integrati¨
onsanforderungen und ihre Uberpr¨
ufung wird in den Abschnitten 9.3.3 und 9.5.3 behandelt.
Auch Begriffssysteme werden i. d. R. ge¨andert, z. B. mit einer neuen Version aktualisiert.
F¨
ur die Modellierung der Tatsache, dass ein Begriffssystem durch eine bestimmte Aufgabe
ist_äquivalent_zu
wird_ausgelöst_durch
0..*
0..*
0..*
0..*
Ereignistyp
0..*
löst_aus
1..*
1..*
1..*
löst_aus
0..*
bearbeitet
wird_ausgelöst_durch
1..*
unter_Berück-
greift_zu_auf
sichtigung_von
Zugriffsart: {interpretierend,
bearbeitend}
Begriffssystem
bearbeitet
ist_Teil_von
0..*
0..*
Objekttyp
ist_Teil_von
0..*
0..*
0..*
greift_zu_auf
0..*
wird_erledigt_in
0..*
0..*
Organisationseinheit
Aufgabe
0..*
0..*
erledigt
0..*
Rolle
0..*
ist_Teil_von
Abbildung 7.7: Erweiterte fachliche Ebene des 3LGM2A ; hervorgehoben sind die neu eingef¨
uhrte Klasse Begriffssystem
und die zuvor in Abschnitt 7.2.1 u
¨berarbeiteten Klassen.
113
¨
7 Flexible Architekturmodellierung — Uberarbeitung
des 3LGM2
Abbildung 7.8: Beispiele f¨
ur die Zuordnung von Begriffssystemen zu greift_zu_auf-beziehungen: Bei der Interpretation und Bearbeitung von Diagnosen und Prozeduren werden die Diagnosenklassifikation ICD10, die Prozedurenklassifikation OPS301 und das Abrechnungssystem DRG angewendet.
bearbeitet wird, z. B. durch Bereitstellung von Aktualisierungen, wird die zus¨
atzliche Assoziationsbeziehung bearbeitet zwischen den Klassen Aufgabe und Begriffssystem eingef¨
uhrt.
Der bearbeitende Zugriff auf ein Begriffssystem kann, ¨
ahnlich dem Zugriff auf Objekttypen, durch Ereignistypen ausgel¨
ost werden oder Ereignistypen ausl¨
osen. Deshalb wird die
Assoziationsbeziehung bearbeitet mit der Klasse Ereignistyp assoziiert.
Die Klasse Begriffssystem ist wie die Klasse Objekttyp mit Anwendungsbaustein, Dokumententyp und Nachrichtentyp assoziiert, d. h. auch Begriffssysteme k¨
onnen gespeichert
und kommuniziert werden. Um f¨
ur ein Begriffssystem ausdr¨
ucken zu k¨
onnen, dass es einen
Master-Anwendungsbaustein hat, ist die Klasse ebenfalls, wie auch Objekttyp, u
¨ ber eine
Assoziationsbeziehung (hat_als_Master) unmittelbar mit der Klasse Anwendungsbaustein
assoziiert (Abbildung 7.9; vgl. Abschnitt 6.3.1).
Abbildung von Begriffssystemen
In manchen Anwendungsszenarios kann der Sachverhalt bestehen, dass in unterschiedlichen
miteinander kommunizierenden Anwendungsbausteinen unterschiedliche Begriffssysteme zur
Interpretation der Daten zur Verf¨
ugung stehen. In diesen F¨
allen ist eine Abbildung von verschiedenen Begriffssystemen auf ein f¨
uhrendes oder, allgemeiner, eine gegenseitige Abbildung
der Begriffssysteme aufeinander erforderlich. Ein Ansatz zur Erf¨
ullung dieser speziellen Integrationsanforderung ist die Verwendung von Terminologieservern ([Ingenerf and Diedrich
1997]).
Das Thema der Abbildung von Begriffssystemen wird hier nicht ausf¨
uhrlich behandelt.
Durch Erg¨
anzung einer reflexiven Assoziationsbeziehung der Klasse Begriffssystem kann
ausgedr¨
uckt werden, dass verschiedene Begriffssysteme mindestens teilweise vergleichbare
Begriffe beschreiben und daher gemeinsam innerhalb eines bestimmten Anwendungsbereiches
verwendet werden k¨
onnen. Bei einer einfachen Analyse der Kommunikation k¨
onnen dann mehrere Begriffssysteme, die u
¨ ber diese Assoziationsbeziehung miteinander in Beziehung stehen, wie ein einziges behandelt werden. Die Assoziationsbeziehung k¨
onnte z. B. den Namen
ist gleichwertig zu“ oder ist Ersatz fuer“ erhalten.
”
”
114
7.7 Einf¨
uhrung der Klasse Begriffssystem
0:.*
Begriffssystem
0:.*
Objekttyp
0..*
rechnerbasierter
Anwendungsbaustein
0..*
Dokumententyp
0..*
0..*
wird_gespeichert_von
0..*
0..*
Customizing: Text
0..*
papierbasierter
Anwendungsbaustein
0:.*
Datenbankverwaltungssystem
0..*
verwaltet_Daten_mit
basiert_auf
1
basiert_auf
0..1
Softwareprodukt
0..*
Standardorganisationsplan (SOP)
0..*
Organisationsplan: Text
0:.*
Nachrichtentyp
0..*
0:.*
0..*
Aufgabe
Anwendungsbaustein
1
0..*
0..*
besitzt
wird_erledigt_in
Organisationseinheit
mit_Hilfe_von
0..1
kann_aufrufen
Nachrichtentyp /
Dokumenttyp
0..*
Benutzungsschnittstelle
wird_
erledigt_in
0..*
0..*
0..*
Kommunikationsschnittstelle
Bausteinschnittstelle
0..* mit_Hilfe_von
0..*
greift_zu_auf
0..1
stellt_bereit
Zugr-art: {interpretierend,
bearbeitend}
stellt_bereit
0..*
0..*
0..*
Kommunikationsbeziehung
kann_aufrufen
hat_Parametertyp
hat_Ergebnistyp
0..*
0..*
0..*
0..*
Operation
0..*
Synchronitätsmodus: {synchron, asynchron}
Transakt.-modus:
{Commit erforderlich,
Commit nicht erford.}
wird_vermittelt_über
1
1
0..*
wird_aktiv_bei
löst_aus
0:.*
0..*
0..*
ist_Teil_von
kann_unterstützen
wird_gespeichert_von
wird_gespeichert_von
0..*
hat_als_Master
wird_ausgelöst_von
0..*
0..*
0..*
hat_als_Master
wird_gespeichert_von
wird_transportiert_über
wird_transportiert_über
0..*
kann_unterstützen
0:.*
0:.*
0..*
Ereignistyp
Abbildung 7.9: Erweiterte logische Werkzeugebene des 3LGM2A mit den Beziehungen der Klasse Begriffssystem zu
den Klassen der logischen Werkzeugebene
115
¨
7 Flexible Architekturmodellierung — Uberarbeitung
des 3LGM2
Netztyp
Anwendungsbaustein
0..*
basiert_auf
ist_installiert_auf
1
0..*
Subnetz
basiert_auf
0..*
0..*
0..*
ist_verbunden_mit
0..*
1..*
gehört_zu
1..*
0..*
0..*
Physischer Datenverarbeitungsbaustein
0..*
hat_Standort 0..1
0..*
0..*
ist_ein
ist_Teil_von
0..1
Bausteintyp
Abbildung 7.10: Physische Werkzeugebene des 3LGM2A
116
Netzprotokoll
Standort
Teil III
Architekturbewertung
117
8 Theoretische Vorbereitung der Integrationsbewertung
8.1 Vorbemerkungen
Dieses Kapitel bereitet, aufbauend auf den Grundlagen zum 3LGM2 in Kapitel 6 und der
Erweiterung des 3LGM2 zum 3LGM2A in Kapitel 7, die Erarbeitung von Ans¨
atzen zur Integrationsbewertung in den folgenden Kapiteln vor. Es werden Interpretationsregeln f¨
ur das
2
3LGMA und weitere theoretische Hilfsmittel definiert, die die Formalisierung der Bewertung
erm¨
oglichen. Dazu geh¨
oren
– Interpretationsregeln f¨
ur Modelle, die Elementhierarchien auf der Basis von ist_Teil_vonBeziehungen enthalten,
– Pr¨
adikate, die bestimmten Assoziationsbeziehungen des 3LGM2A entsprechen,
– erg¨
anzende Pr¨
adikate f¨
ur das Ausdr¨
ucken komplexerer Sachverhalte unter Nutzung der
erstgenannten Pr¨
adikate und
– eine Tupelnotation f¨
ur Kommunikationsbeziehungen.
Hinweise
Hinweis zur Syntax: Das Kapitel greift auf die in den Kapiteln 6 und 7 vorgestellten Elemente
uck. Wie dort sind die Begriffe des 3LGM2 bzw. 3LGM2A in einer
des 3LGM2 bzw. 3LGM2A zur¨
anderen Schriftart gesetzt. Auch die hier eingef¨
uhrten Pr¨
adikate sind in einer anderen
Schriftart gesetzt.
Hinweise zur Ausdrucksweise: Anstelle der l¨
angeren Formulierung Eintreten eines Ereignisses
”
des Typs ergt“ wird im Folgenden immer kurz Eintreten des Ereignistyps ergt“ bzw. k¨
urzer
”
Eintreten von ergt“ geschrieben. Ebenfalls zur Vereinfachung wird f¨
ur einen Anwendungsbau”
stein awb und einen Objekttyp objt immer awb ben¨
otigt objt“ anstelle von awb ben¨
otigt
”
”
Daten zu objt“ geschrieben.
8.2 Die Interpretation von Elementhierarchien
Das 3LGM2A sieht, wie bereits das 3LGM2 , ist_Teil_von-Beziehungen f¨
ur verschiedene Elementtypen vor (vgl. Abbildungen 6.1a, 6.2a und 6.3a). Damit k¨
onnen Hierarchien von Elementen desselben Typs (von Instanzen derselben Elementklasse) gebildet werden (Abbildung 8.1).
Im Zusammenhang mit der Bildung solcher Elementhierarchien muss die Interpretation der
u
azisiert werden.
¨ brigen Assoziationsbeziehungen, z. B. greift_zu_auf, pr¨
Wenn keine u
¨ ber ist_Teil_von-Beziehungen modellierten Elementhierarchien existieren,
k¨
onnen die u
achst ohne zus¨
atzliche Vereinba¨ brigen Assoziationsbeziehungen des 3LGM2A zun¨
rungen interpretiert werden. Eine Instanz der Assoziationsbeziehung greift_zu_auf zwischen
einer Aufgabe auf1 und einem Objekttyp objt bedeutet ohne zus¨
atzliche Definitionen, dass
bei der Erf¨
ullung von auf1 auf Informationen zu Objekten des Typs objt zugegriffen wird1 .
1
Zur Vereinfachung wird ein derartiger Sachverhalt im folgenden in der verk¨
urzten Form auf1 greift auf objt
”
119
8 Theoretische Vorbereitung der Integrationsbewertung
Abbildung 8.1: Interpretation von ist_Teil_von-Beziehungen
Fraglich ist nun, ob auf objt auch dann von auf zugegriffen wird, wenn beide nicht unmittelbar u
upft sind. Wie wird ein Modell interpretiert,
¨ ber eine greift_zu_auf-Beziehung verkn¨
in dem auf1 mit Hilfe von ist_Teil_von-Beziehungen u
¨ ber- oder untergeordnete Aufgaben
zugeordnet wurden, die mit objt verkn¨
upft sind?
F¨
ur die Auswertung von ist_Teil_von-Beziehungen wird hier definiert:
Definition 8.1 F¨
ur ein Modellelement me in einem 3LGM2A -basierten Modell gelten alle
Angaben bzw. Beziehungen zu anderen Modellelementen, die f¨
ur u
¨ bergeordnete Elemente
von me gelten. Die G¨
ultigkeit besteht dabei auch transitiv u
¨ ber mehrere aufeinanderfolgende
ist_Teil_von-Beziehungen.
Angaben bzw. Beziehungen, die f¨
ur untergeordnete Elemente, d. h. Teilelemente, von me
gelten, gelten ohne weitere Angaben oder Beziehungen nicht notwendigerweise f¨
ur me.
Ende — Definition
Bezogen auf die genannten Beispielelemente auf1 und objt bedeutet die Definition, dass das
Zugreifen auf objt durch eine u
¨ bergeordnete Aufgabe auf2 von auf1 auch das Zugreifen auf
objt durch auf1 impliziert. Wenn die zus¨
atzliche Aufgabe auf2 Teilaufgabe von auf1 ist, kann
aus dem Zugreifen von auf2 auf objt jedoch nicht das Zugreifen von auf1 auf objt abgeleitet
werden (vgl. Abbildung 8.1).
8.3 Mengen f¨
ur Klassen des 3LGM2A
In den theoretischen Vorbereitungen der folgenden Abschnitte und auch bei der Anwendung
dieser Vorbereitungen in den folgenden Kapiteln werden sehr oft Mengensymbole angegeben.
Diese Mengensymbole werden verwendet, um die Zugeh¨
origkeit von bestimmten Variablen zu
zu“ o. ¨
a. formuliert.
120
8.4 Pr¨
adikate zu Assoziationsbeziehungen des 3LGM2A
den Instanzmengen der Klassen des 3LGM2A zu kennzeichnen. Die Angabe auf ∈ AUF bedeutet
beispielsweise, dass die Variable auf zur Menge aller Aufgaben geh¨
ort, d. h. dass auf f¨
ur eine
Instanz der Klasse Aufgabe steht.
F¨
ur die verwendeten Mengensymbole werden hier semiformale Definitionen angegeben:
1. Mengen f¨
ur Klassen der fachlichen Ebene des 3LGM2A :
AUF
:=
{x | x ist eine Aufgabe.}
(8.1)
GZA
:=
{x | x ist eine greift_zu_auf-Beziehung.}
(8.2)
OBJT
:=
{x | x ist ein Objekttyp.}
(8.3)
OE
:=
{x | x ist eine Organisationseinheit.}
(8.4)
ROL
:=
{x | x ist eine Rolle.}
(8.5)
WEI
:=
{x | x ist eine wird_erledigt_in-Beziehung.}
(8.6)
(8.7)
2. Mengen f¨
ur Klassen der logischen Werkzeugebene des 3LGM2A :
AWB
:=
RAWB ∪ PAWB
BNS
:=
{x | x ist eine Benutzungsschnittstelle.}
(8.8)
BSS
:=
{x | x ist eine Bausteinschnittstelle.}
(8.10)
(8.11)
(8.9)
DBVS
:=
{x | x ist ein Datenbankverwaltungssystem.}
DOKT
:=
{x | x ist ein Dokumententyp.}
(8.12)
ERGT
:=
{x | x ist ein Ereignistyp.}
(8.13)
KA
:=
{x | x ist eine kann_aufrufen-Beziehung.}
(8.14)
KOMB
:=
{x | x ist eine Kommunikationsbeziehung.}
(8.15)
KOMS
:=
{x | x ist ein Kommunikationsstandard.}
(8.16)
NACT
:=
{x | x ist ein Nachrichtentyp.}
(8.17)
PAWB
:=
{x | x ist ein papierbasierter Anwendungsbaustein.}
(8.18)
RAWB
:=
{x | x ist ein rechnerbasierter Anwendungsbaustein.}
(8.19)
SB
:=
{x | x ist eine stellt_bereit-Beziehung.}
(8.20)
SOP
:=
{x | x ist ein Standardorganisationsplan.}
(8.21)
SWP
:=
{x | x ist ein Softwareprodukt.}
(8.22)
(8.23)
3. Mengen f¨
ur Klassen der physischen Werkzeugebene des 3LGM2A :
PDVB
:=
{x | x ist ein physischer Datenverarbeitungsbaustein.}
(8.24)
8.4 Pr¨
adikate zu Assoziationsbeziehungen des 3LGM2A
In den folgenden Kapiteln zur Bewertung der Informationssystemarchitektur wird mehrfach
ein formales Hilfsmittel ben¨
otigt, mit dem Tatsachen hinsichtlich der Beziehungen bestimmter
Modellelemente, d. h. bestimmter Instanzen der Klassen des 3LGM2A , augedr¨
uckt werden kann.
Definition 8.2 F¨
ur jede Assoziationsbeziehung des 3LGM2A sei ein gleichnamiges Pr¨
adikat
verf¨
ugbar. F¨
ur die als Parameter anzugebenden Modellelemente zeigt das betreffende Pr¨
adikat
an, ob zwischen diesen Modellelementen eine Instanz der zugeh¨
origen Assoziationsbeziehung
121
8 Theoretische Vorbereitung der Integrationsbewertung
existiert2 .
Ende — Definition
F¨
ur die fachliche Ebene des 3LGM2A stehen mit Definition 8.2 u. a. folgende Pr¨
adikate zur
3
Verf¨
ugung (vgl. Kapitel 6.2.1 und Abschnitt 7.2.1):
ist_Teil_von(auf1 ∈ AUF, auf2 ∈ AUF)
:=
auf1 ist Teil von auf2 .
(8.25)
greift_zu_auf(auf ∈ AUF, objt∈ OBJT)
:=
auf greift auf objt zu.
(8.26)
loest_aus(ergt∈ ERGT, gza∈ GZA)
:=
ergt l¨
ost aus gza.
(8.27)
wird_erledigt_in(auf1 ∈ AUF, oe∈ OE)
:=
auf wird erledigt in oe.
(8.28)
F¨
ur die logische Werkzeugebene des 3LGM2A stehen mit Definition 8.2 u. a. folgende Pr¨
adikate zur Verf¨
ugung (vgl. Abschnitte 6.3.2 und 7.2.2):
basiert_auf(rawb∈ RAWB, swp∈ SWP)
:=
rawb basiert auf swp zu.
besitzt(awb∈ AWB, bss∈ BSS)
:=
awb besitzt bss.
(8.29)
(8.30)
stellt_bereit(bss∈ BSS, op∈ OP)
:=
bss stellt op bereit.
(8.31)
kann_aufrufen(bss∈ BSS, op∈ OP)
:=
bss kann op aufrufen.
(8.32)
kommunikationsbeziehung(bss1 ∈ BSS, bss2 ∈ BSS, op∈ OP)
:=
bss1 ruft op bei bss2 auf.
(8.33)
F¨
ur die physische Werkzeugebene des 3LGM2A steht mit Definition 8.2 u. a. folgendes Pr¨
adikat zur Verf¨
ugung (vgl. Abschnitt 6.2.3):
ist_verbunden_mit(pdvb1 ∈ PDVB, pdvb2 ∈ PDVB)
:=
pdvb1 ist mit pdvb2 verbunden.
(8.34)
Mit der in Abschnitt 8.2 definierten Interpretation der ist_Teil_von-Beziehungen l¨
asst sich
u. a. folgende Ableitung vornehmen:
ist_Teil_von(auf1 , auf2 ) ∧ greift_zu_auf(auf2 , objt)
→ greift_zu_auf(auf1 , objt)
8.5 Zusammengesetzte Pr¨
adikate f¨
ur die Unterst¨
utzung der Bewertung
Auf der Basis der Pr¨
adikate zu den Assoziationsbeziehungen werden hier weitere Pr¨adikate
definiert, die das formale Bewerten der Architektur erm¨
oglichen.
8.5.1 Die Pr¨
adikate ben¨
otigt und unterst¨
utzt
Um die Tatsache, dass ein Anwendungsbaustein bestimmte Informationen verarbeitet, formalisiert ausdr¨
ucken zu k¨
onnen, wird hier das Pr¨
adikat benoetigt(awb, ergt, objt) definiert. Das
Pr¨
adikat gibt f¨
ur einen Anwendungsbaustein awb und einen Objekttyp objt an, ob in awb
objt ben¨
otigt wird.
2
3
Die Definition nutzt die M¨
oglichkeit, mit UML definierte Assoziatiosbeziehungen als Klassen aufzufassen.
Auf eine vollst¨
andige Auflistung aller m¨
oglichen Pr¨
adikate wird hier verzichtet.
122
8.5 Zusammengesetzte Pr¨
adikate f¨
ur die Unterst¨
utzung der Bewertung
Die Berechnungsvorschrift f¨
ur benoetigt ist: awb ben¨
otigt objt genau dann, wenn awb eine
Aufgabe auf unterst¨
utzt, die auf objt zugreift:
benoetigt(awb∈ AWB, objt∈ OBJT)
:=
unterstuetzt(awb, auf ) ∧
∃auf ∈ AUF greift_zu_auf(auf, objt)
(8.35)
Das verwendete Pr¨
adikat unterstuetzt gibt dabei f¨
ur einen Anwendungsbaustein awb und
eine Aufgabe auf an, dass auf mit Hilfe von awb erledigt wird. Die Berechnung wird, mit
Ausnahme der erweiterten Form des Pr¨
adikates wird_erledigt_in, aus Pr¨
adikaten zusammengesetzt, die unmittelbar Assoziationsbeziehungen im 3LGM2A entprechen:
1
wird_erledigt_in(auf, oe, wei)
oe∈ OE
∃ wei∈ WEIA mit_Hilfe_von(wei, bns)
bns∈ BNS besitzt(awb, bns)
∨
0
1
wird_erledigt_in(auf, oe, wei)
oe∈ OE
Bwei∈ WEIC mit_Hilfe_von(wei, op)
C
∃B
op∈ OP A stellt_bereit(bss, op)
besitzt(awb, bss)
bss∈ BSS
0
unterstuetzt(awb∈ AWB, auf ∈ AUF)
:=
∧
∧
∧
∧
∧
(8.36)
Die besondere Form des Pr¨
adikates wird_erledigt_in zur Assoziationsklasse wird_erledigt_in des 3LGM2A wurde gew¨
ahlt, um die ggf. existierende Beziehung zwischen auf und der Orgaonnen.
nisationseinheit org als Parameter f¨
ur das Pr¨
adikat mit_Hilfe_von verwenden zu k¨
Das Pr¨
adikat ist folgendermaßen semiformal definiert:
wird_erledigt_in(auf ∈ AUF, oe∈ OE, wei∈ WEI)
:=
auf wird in oe erledigt und wei ist die Instanz der
Assoziationsklasse wird_erledigt_in, die diese
Tatsache ausdr¨
uckt.
(8.37)
8.5.2 Das Pr¨
adikat wird angewendet auf
uckt werden, dass bei der InterpreMit Hilfe des Pr¨
adikates wird_angewendet_auf kann ausgedr¨
tation oder Bearbeitung eines Objekttyps ein bestimmtes Begriffssystem zu ber¨
ucksichtigen
ist bzw. angewendet wird.
Das Pr¨
adikat wird_angewendet_auf gibt an, dass ein bestimmtes Begriffssystem bei Zugriffen auf einen bestimmten Objekttyp ber¨
ucksichtigt wird:
wird_angewendet_auf(bgs∈ BGS, objt∈ OBJT) := ∃
auf ∈ AUF greift_zu_auf(auf, objt, gza)
∧
(8.38)
gza∈ GZA unter_Beruecksichtigung_von(gza, bgs)
Die hier verwendete erweiterte Form des Pr¨
adikates greift_zu_auf zur Assoziationsklasse
greift_zu_auf des 3LGM2A wurde gew¨
ahlt, um die ggf. existierende Beziehung zwischen auf
und objt als Parameter f¨
ur das Pr¨
adikat unter_Beruecksichtigung_von verwenden zu k¨
onnen.
Das Pr¨
adikat ist in der erweiterten Form folgendermaßen semiformal definiert:
greift_zu_auf(auf ∈ AUF, objt∈ OBJT, gza∈ GZA)
:=
auf greift auf objt zu und gza ist die Instanz (8.39)
der Assoziationsklasse greift_zu_auf, die diese
Tatsache ausdr¨
uckt.
123
8 Theoretische Vorbereitung der Integrationsbewertung
8.5.3 Pr¨
adikate f¨
ur die Analyse von Kommunikation
¨
Ubermittlung
von Informationen
Objekttypen werden zwischen Anwendungsbausteinen dadurch u
¨ bermittelt, dass Operationen mit bestimmten Nachrichtentypen bzw. Dokumententypen aufgerufen werden. Der Aufruf
von Operationen wird durch das Eintreten von Ereignissen gesteuert. In Abschnitt 6.3.2 wurde dazu bereits die Klasse Ereignistyp vorgestellt und in Abschnitt 7.2.1 hinsichtlich ihrer
Beziehungen zu anderen Klassen des 3LGM2A u
¨ berarbeitet.
Zur Beschreibung der Tatsache, dass ein Objekttyp objt bei Eintreten des Ereignistyps
ergt von Anwendungsbaustein awb1 an Anwendungsbaustein awb2 u
¨ bermittelt wird, wird hier
das Pr¨
adikat wird_ueber- mittelt eingef¨
uhrt:
0
1
objt∈ OBJT,
Bergt∈ ERGT,C
C
wird_uebermittelt B
awb1 ∈ AWB, A
awb2 ∈ AWB
besitzt(awb1 , bss1 )
∧
∧
besitzt(awb2 , bss2 )
0
1 ( ( kann_aufrufen(bss1 , op, ka) ∧
bss1 ∈ BSS
stellt_bereit(bss2 , op, sb) ∧
Bbss2 ∈ BSS
C
hat_Parametertyp(op, ndt) ∧
B
C
Bka∈ KA
C
kommunikationsbeziehung(ka, sb, komb)) ∨
B
C
:= ∃ Bsb∈ SB
(8.40)
C
B
C ( kann_aufrufen(bss2 , op, ka) ∧
Bkomb∈ KOMB
C
stellt_bereit(bss
,
op,
sb)
∧
op∈ OPER
A
1
hat_Ergebnistyp(op, ndt) ∧
ndt∈ NACT ∪ DOKT kommunikationsbeziehung(ka, sb, komb) ) ) ∧
∧
wird_repraesentiert_durch(objt, ndt)
wird_aktiv_bei(komv, ergt)
Das verwendete Pr¨
adikat kommunikationsbeziehung entspricht der Assoziationsklasse Kommunikationsbeziehung des 3LGM2A und ¨
ahnelt in seiner erweiterten Form dem in der Definitionsformel 8.36 verwendeten Pr¨
adikat wird_erledigt_in. Es erlaubt die Weiterverwendung
der ggf. existierenden Kommunikationsbeziehung zwischen bss1 und bss2 als Parameter f¨
ur das
Pr¨
adikat wird_aktiv_bei. Das Pr¨
adikat ist folgendermaßen semiformal definiert:
kommunikationsbeziehung
ka∈ KA, sb∈ SB,
komb∈ KOMB
:=
ka und sb stehen in einer Kommunikationsbeziehung zueinander und komb ist die Instanz der Assoziationsklasse Kommunikationsbeziehung, die
diese Tatsache ausdr¨
uckt.
(8.41)
Gleiches gilt f¨
ur die erweiterten Formen der Pr¨
adikate kann_aufrufen und stellt_bereit, die
die Weiterverwendung der Variablen ka und sb als Parameter des Pr¨
adikates kommunikationsbeziehung erm¨
oglichen:
kann_aufrufen(bss∈ BSS, op∈ OPER, ka∈ KA)
:=
stellt_bereit(bss∈ BSS, op∈ OPER, sb∈ SB)
:=
bss kann op aufrufen und ka ist die Instanz der
Assoziationsklasse kann_aufrufen, die diese Tatsache ausdr¨
uckt.
bss stellt op bereit und sb ist die Instanz der Assoziationsklasse stellt_bereit, die diese Tatsache ausdr¨
uckt.
(8.42)
(8.43)
Das Pr¨
adikat wird_uebermittelt ist transitiv auszuwerten, d. h. wenn wird_uebermittelt
(objt, ergt, awb1 , awb2 ) und wird_uebermittelt(objt, ergt, awb2 , awb3 ) gelten, dann gilt auch
wird_- uebermittelt(objt, ergt, awb1 , awb3 ).
124
8.5 Zusammengesetzte Pr¨
adikate f¨
ur die Unterst¨
utzung der Bewertung
¨
Ubermittlung
von Informationen zu Begriffssystemen
Im 3LGM2A ist auch f¨
ur Begriffssysteme die Modellierung der Speicherung und der Kom¨
munikation vorgesehen (vgl. Abschnitt 7.7). Daher kann auch f¨
ur Begriffssysteme die Ubermittlung formal untersucht werden.
¨
Wie f¨
ur Objekttypen wird hier ein Pr¨
adikat definiert, das die Ubermittlung
eines Begriffssystems bgs bei Eintreten eines Ereignistyps ergt von Anwendungsbaustein awb1 an Anwendungsbaustein awb2 anzeigt:
besitzt(awb1 , bss1 )
∧
∧
besitzt(awb2 , bss2 )
0
1 ( ( kann_aufrufen(bss1 , op, ka) ∧
bss1 ∈ BSS
stellt_bereit(bss2 , op, sb) ∧
0
1
Bbss2 ∈ BSS
C
hat_Parametertyp(op, ndt) ∧
bgs∈ BGS,
B
C
Bka∈ KA
C
Bergt∈ ERGT,C
kommunikationsbeziehung(ka, sb, komb)) ∨
B
C
C
sb∈ SB
wird_uebermittelt B
(8.44)
C
awb1 ∈ AWB, A := ∃ B
B
C ( kann_aufrufen(bss2 , op, ka) ∧
Bkomb∈ KOMB
C
awb2 ∈ AWB
stellt_bereit(bss1 , op, sb) ∧
op∈ OPER
A
hat_Ergebnistyp(op, ndt) ∧
ndt∈ NACT ∪ DOKT kommunikationsbeziehung(ka, sb, komb) ) ) ∧
∧
wird_repraesentiert_durch (bgs, ndt)
wird_aktiv_bei(komv, ergt)
Auch das Pr¨
adikat wird_uebermittelt_b ist, wie wird_uebermittelt, transitiv auszuwerten.
Aufrufen von Funktionalit¨
at
¨
uckt, dass ein beUber
das in der Formel 8.36 definierte Pr¨
adikat unterstuetzt wird ausgedr¨
stimmter Anwendungsbaustein Funktionalit¨
at zur Erf¨
ullung einer oder mehrerer Aufgaben
implementiert. Wie bereits am Ende von Abschnitt 7.2.2 beschrieben, ist bei sehr detaillierter
Betrachtung der Funktionalit¨
atsbereitstellung eine entsprechend detaillierte Modellierung von
Aufgaben erforderlich.
Das Bereitstellen der implementierten Funktionalit¨
at durch den betreffenden Anwendungsbaustein f¨
ur andere Anwendungsbausteine wird mit Hilfe der Klassen Bausteinschnittstelle und Operation modelliert.
¨
¨
Ahnlich
der Ubermittlung
von Informationen kann auch modelliert werden, dass Anwendungsbausteine Funktionalit¨
at, die durch andere Anwendungsbausteine bereitgestellt wird,
nutzen bzw. aufrufen. Funktionalit¨
at, d. h. die F¨
ahigkeit zur Erf¨
ullung bestimmter Aufgaben,
wird von Anwendungsbausteinen dadurch von anderen Anwendungsbausteinen aufgerufen,
dass Operationen beim Eintreten bestimmter Ereignistypen aufgerufen werden.
Zur Beschreibung der Tatsache, dass Funktionali¨
at zur Erf¨
ullung einer Aufgabe auf bei
Eintreten des Ereignistyps ergt von Anwendungsbaustein awb1 bei Anwendungsbaustein
awb2 aufgerufen wird, dient hier das Pr¨
adikat ruft_auf:
0
1
bss1 ∈ BSS
Bbss2 ∈ BSS
C
auf, ergt,
B
C
ruft_auf
:= ∃ Bkomb∈ KOMBC awb1 , awb2
op∈ OPER
A
nact∈ NACT
besitzt(awb1 , bss1 )
∧
besitzt(awb2 , bss2 )
∧
stellt_bereit(bss2 , op, sb)
∧
kann_aufrufen(bss1 , op, ka)
∧
kommunikationsbeziehung(ka, sb, komb)∧
unterstuetzt(op, auf )
∧
wird_aktiv_bei(komb, ergt)
(8.45)
Das Pr¨
adikat ruft_auf ist transitiv auszuwerten, d. h. wenn ruft_auf(auf, ergt, awb1 , awb2 )
125
8 Theoretische Vorbereitung der Integrationsbewertung
und ruft_auf(auf, ergt, awb2 , awb3 ) gelten, dann gilt auch ruft_auf(auf, ergt, awb1 , awb3 ).
8.6 Formalisierung von Kommunikationsverbindungen
Aufbauend auf der Definition aus Abschnitt 7.5 wird der Begriff Kommunikationsverbindung
hier formalisiert.
8.6.1 Kommunikationsverbindungen als Folgen von Kommunikationsbeziehungen
Das 3LGM2 definiert Kommunikationsbeziehungen als Assoziationsbeziehungen, die zwei Bausteinschnittstellen miteinander verbinden. F¨
ur die beiden Bausteinschnittstellen muss
gelten, dass die aufgerufene Bausteinschnittstelle eine Operation bereit stellt, die die aufrufende Bausteinschnittstelle aufrufen kann.
Jede Kommunikationsbeziehung kann als Tripel (bss1 , bss2 , op) aufgefasst werden:
bss1 := aufrufende Bausteinschnittstelle
kb = (bss1 , bss2 , op) bss2 := aufgerufene Bausteinschnittstelle
op := aufgerufene Operation
(8.46)
¨
Jeder Weg zur Ubermittlung
von Daten bzw. Funktionalit¨
at von einem Anwendungsbaustein
zu einem anderen wird hier als Kommunikationsverbindung bezeichnet. Eine Kommunikationsverbindung kann dabei aus mehreren Kommunikationsbeziehungen bestehen.
Jede Kommunikationsverbindung kann als eine Folge von Kommunikationsbeziehungen betrachtet werden:
kv = hkbi i = hkb1 , . . . , kbn i = h(bss1,1 , bss1,2 , op1 ), . . . , (bssn,1 , bssn,2 , opn )i
(8.47)
Es ergibt sich unmittelbar, was unter der L¨
ange einer Kommunikationsverbindung verstanden
wird: Die L¨
ange einer Kommunikationsverbindung ist gleich der Anzahl der zugeh¨
origen Kommunikationsbeziehungen:
L(kv) := |hkbi i|
(8.48)
8.6.2 Vermittlung und Vermittlungstiefe
Kommunikationsbeziehungen k¨
onnen, entsprechend der in Abschnitt 7.2.2 beschriebenen Er2
weiterung des 3LGM , u
¨ ber spezielle Kommunikationsbeziehungen vermittelt werden (vgl.
auch Abschnitt 7.4.2). In der hier gew¨
ahlten Tupelnotation f¨
ur Kommunikationsbeziehungen
wird Vermittlung als zus¨
atzliches Tupelelement notiert. Eine Kommunikationsbeziehung kann
also als Quadrupel (bss1 , bss2 , op, hvb1 , . . . , vbn i) aufgefasst werden:
bss1
:= aufrufende Bausteinschnittstelle
bss2
:= aufgerufene Bausteinschnittstelle
kb = (bss1 , bss2 , op, hvb1 , . . . vbn i) op
:= aufgerufene Operation
ori hvb1 , . . . vbn i:= Vermittlungsverbindung als Folge der zugeh¨
gen Kommunikationsbeziehungen
(8.49)
In vielen F¨
allen werden vermittelnde Kommunikationsbeziehungen (= Vermittlungsbezie-
126
8.6 Formalisierung von Kommunikationsverbindungen
(bss1 , bss2 , op, h (vbss1,1 , vbss1,2 , vop1 , h (vvbss1,1,1 , vvbss1,1,2 , vvop1,1 , hi ) i ), (vbss2,1 , vbss2,2 , vop2 , hi ) i )
oder u
¨bersichtlicher:
(bss1 , bss2 , op,
)
h (vbss1,1 , vbss1,2 , vop1 ,
), (vbss2,1 , vbss2,2 , vop2 ,
h (vvbss1,1,1 , vvbss1,1,2 , vvop1,1 ,
)i
)i
hi
hi
Abbildung 8.2: Beispiel f¨
ur eine Kommunikationsverbindung mit Vermittlungsbeziehungen
hungen) selbst durch weitere Kommunikationsbeziehungen vermittelt. Mit der Anwendung
der Quadrupelnotation f¨
ur die vermittelnden Kommunikationsbeziehungen kann diese Tatsache ausgedr¨
uckt werden, wodurch sich bei ausf¨
uhrlicher Notation einer Kommunikationsbeziehung m¨
oglicherweise Verschachtelungen ergeben. Abbildung 8.2 zeigt ein Beispiel f¨
ur eine
Kommunikationsverbindung mit Vermittlungsbeziehungen.
Die Vermittlungstiefe einer Kommunikationsverbindung entspricht der maximalen Schachtelungstiefe der zugeh¨
origen Vermittlungsbeziehungen:
T (kv) := max. Schachtelungstiefe der Vermittlungsbeziehungen
(8.50)
Im Beispiel von Abbildung 8.2 betr¨
agt die Vermittlungstiefe also 2.
127
9 Die Erf¨
ullung von Integrationsanforderungen
Die bisherigen Ausf¨
uhrungen zur Modellierung von Informationssystemen auf der Basis des
3LGM2A waren haupts¨
achlich auf das Modellieren unterschiedlicher Architekturen ohne das
Vornehmen einer Bewertung bezogen. Dieses Kapitel nimmt die am Anfang der Arbeit in
Kapitel 1 angek¨
undigte Bewertungsthematik auf.
Nach einer Vorbereitung in den Abschnitten 9.1 und 9.2 wird in Abschnitt 9.3 beschrieben,
wie Integrationsanforderungen auf der Basis des 3LGM2A modelliert bzw. aus existierenden
Modellen abgeleitet werden k¨
onnen. Dabei werden die in den Abschnitten 8.2 bis 8.5 definierten
Interpretationsregeln sowie Mengen- und Pr¨
adikatdefinitionen verwendet.
In den Abschnitten 9.4 und 9.5 wird beschrieben, wie die Erf¨
ullung von Integrationsanfor2
derungen formal auf der Basis von 3LGMA -Modellen u
uft werden kann.
¨ berpr¨
9.1 Mengen von Anwendungsbausteinen: Dom¨
anen
Mengen von Anwendungsbausteinen, f¨
ur die bestimmte Integrationsanforderungen bestehen
oder f¨
ur die u
¨ ber Kommunikationsverbindungen Integration hergestellt wurde, werden im Folgenden als Dom¨anen bezeichnet. Dazu werden in den Abschnitten 9.3 und 9.4 zwei Dom¨
anentypkategorien mit verschiedenen Dom¨
anentypen definiert:
Anforderungsdom¨
anen enthalten Anwendungsbausteine, f¨
ur die bestimmte Integrationsanforderungen bestehen. Dazu wurden in Kapitel 2 bereits Anforderungskategorien beschrieben. Zu jeder Anforderungskategorie, mit Ausnahme der physischen Integration
¨
(s. u.), wird ein Anforderungsdom¨
anentyp definiert. Uber
verschiedene Parameter k¨
onnen, bezogen auf ein Modell, konkrete Anforderungsdom¨
anen bestimmt werden.
Kommunikationsdom¨
anen enthalten Anwendungsbausteine, bei denen u
¨ ber Kommunikationsverbindungen ein bestimmter Integrationsstatus hergestellt wurde. Es werden zwei
Kommunikationsdom¨
anentypen definiert, die die Integration hinsichtlich bestimmter Informationen bzw. hinsichtlich bestimmter Funktionalit¨
at fokussieren. Konkrete Kommunikationsdom¨
anen in einem Modell werden, wie Anforderungsdom¨
anen, u
¨ ber verschiedene
Parameter bestimmt.
¨
Uber
das Vergleichen von Anforderungsdom¨
anen mit Kommunikationsdom¨
anen kann die Architektur eines Informationssystems hinsichtlich der Erf¨
ullung von Integrationsanforderungen
bewertet werden. In Abschnitt 9.5 werden auf der Basis der Dom¨
anentypdefinitionen Anleitungen f¨
ur das Vergleichen und Beispiele angegeben.
Das systematische Analysieren und Bewerten von physischer Integration wird, im Gegensatz
zu den anderen Anforderungskategorien, nicht behandelt. Eine ausf¨
uhrliche Behandlung und
¨
Uberarbeitung
der physischen Werkzeugebene des 3LGM2 erfolgt in einer weiteren Dissertation
mit dem Arbeitstitel Modellierung und Bewertung der hardwarenahen Systemkonfigurationen
”
129
9 Die Erf¨
ullung von Integrationsanforderungen
Abbildung 9.1: Auszug aus der fachlichen Ebene des Informationssystems des UKL
von KIS zur Unterst¨
utzung des strategischen IM“. Diese Dissertation wird in derselben Arbeitsgruppe erstellt, in der auch der Autor der vorliegenden Arbeit t¨
atig ist.
9.2 Ein Anwendungsszenario
Zur Demonstration der Anwendung des in diesem Kapitel vorgestellten Dom¨
anenkonzeptes werden mehrfach Beispiele aus dem Informationssystem des Universit¨
atsklinikums Leipzig (UKL)
verwendet.
Das Informationssystem des UKL wurde auf der Basis des 3LGM2 modelliert. Die in diesem
Kapitel verwendeten Beispiele sind auf Ausz¨
uge dieses Modells bezogen. Je nach Beispiel wird
eines von zwei Teilmodellen betrachtet: Das erste Teilmodell beschreibt das Zusammenwirken
des Patientenverwaltungssystems mit anderen, f¨
ur die medizinische Informationsverarbeitung
genutzten Anwendungsbausteinen. Das zweite beschreibt spezieller das Zusammenwirken des
Patientenverwaltungssystems und des R/3-basierten Klinischen Dokumentations- und Managementsystems mit dem Radiologieinformationssystem und bestimmten PACS-Komponenten.
Abbildung 9.1 zeigt die f¨
ur beide Teilmodelle gleiche fachliche Ebene des Informationssystems,
die Abbildungen 9.2a und b zeigt die beiden unterschiedlichen logischen Werkzeugebenen. Von
der physischen Werkzeugebene wird nur ein einziges Element, ein PC, genutzt.
130
9.2 Ein Anwendungsszenario
Elemente
Hinweise
Fachliche Ebene
Aufgabe Patientenaufnahme (station¨
ar)
das Aufnehmen (Registrieren) station¨
arer Patienten
Aufgabe Diagnosen- und Prozedurenverschl¨
usseGesetzlich vorgeschriebene Pflicht zur Verschl¨
usselung von
lung
Diagnosen und Prozeduren f¨
ur die station¨
are Abrechnung
nach der Diagnosenklassifikation ICD10 und der Prozedurenklassifikation OPS301
¨
Aufgabe Rechtepr¨
ufung MRZ
Uberpr¨
ufung von Benutzerrechten im Klinikumsnetzwerk des
UKL
Objekttyp Fall
die im Informationssystem registrierten Behandlungsf¨
alle
→ Bearbeitung l¨
ost aus:
Ereignistyp NP11I0
Kommunikationsstandard SAP-HCM ; wird beim Registrieren einer station¨
aren Patientenaufnahme (Anlegen eines station¨
aren Falles) ausgel¨
ost
→ Interpretation l¨
ost aus:
Ereignistyp Kontextwechsel Fall
wird beim Ausw¨
ahlen eines Behandlungsfalles in einem
Anwendungsbaustein ausgel¨
ost
→ Interpretation wird ausgel¨
ost durch:
Ereignistyp RIS Fall Abfrage
Objekttyp Diagnose
wird ausgel¨
ost, wenn aus dem Radiologieinformationssystem
(RIS) Falldaten aus seinem Kommunikationsmodul abgefragt
werden sollen
die f¨
ur die Abrechnung, aber auch f¨
ur die Erstellung von Arztbriefen zu dokumentierenden Diagnosen
→ Bearbeitung l¨
ost aus:
Ereignistyp DIAPROZ init
wird beim Initiieren der Verschl¨
usselung von Diagnosen oder
Prozeduren ausgel¨
ost
→ erfordert die Ber¨
ucksichtigung von:
Begriffssystem ICD10
bei der Diagnosendokumentation anzuwendende Klassifikation
→ Bearbeitung l¨
ost aus:
Ereignistyp ICD neu
Begriffssystem DRG
Objekttyp Prozedur
wird beim Einpflegen einer aktualisierten Version des Begriffssystems ICD10 ausgel¨
ost
bei der Abrechnung anzuwendende Klassifikation f¨
ur Behandlungsf¨
alle; ber¨
ucksichtigt die zum Fall dokumentierten
ICD10-Diagnosen, OPS301-Prozeduren und weitere Angaben
zum Patienten oder zum Behandlungsverlauf
die f¨
ur die Abrechnung, aber auch f¨
ur die Erstellung von Arztbriefen zu dokumentierenden medizinischen Maßnahmen
→ erfordert die Ber¨
ucksichtigung von:
Begriffssystem OPS301
Begriffssystem DRG
Objekttyp Mitarbeiter des Pflegedienstes
bei der Prozedurendokumentation anzuwendende Klassifikation
(s. o.)
Mitarbeiter des Pflegedienstes in der Klinik f¨
ur Neurochirurgie; umfasst u. a. auch Informationen u
¨ber Zugriffsberechtigungen dieser Mitarbeiter
→ Bearbeitung l¨
ost aus:
Ereignistyp ZUGR update
wird beim Aktualisieren von Zugriffsinformationen, z. B.
beim Objekttyp Mitarbeiter des Pflegedienstes ausgel¨
ost
→ Interpretation l¨
ost aus:
Ereignistyp LOGIN BBS
Anwendungsbaustein
tem
wird
bei
der
Anmeldung
eines
Benutzers
am
Anwendungsbaustein Bild- und Befundserver ausgel¨
ost
Logische Werkzeugebene
Patientenverwaltungssys- zentrales Werkzeug f¨
ur Aufgaben im Zusammenhang mit der
Patientenverwaltung, z. B. das Anlegen von F¨
allen, das Registrieren von Verlegungen und Entlassungen sowie das Erstellen von Rechnungen; u. a. Master-Anwendungsbaustein
f¨
ur den Objekttyp Fall.
→ kann u
¨ ber eine Bausteinschnittstelle aufrufen:
Operation ADT-Nachrichten¨
ubergabe
nimmt Nachrichten zu ADT-Ereignissen als Parameter entgegen
Tabelle 9.1: Elemente des Beispielmodells des Informationssystems des UKL
131
9 Die Erf¨
ullung von Integrationsanforderungen
a)
b)
Abbildung 9.2: Ausz¨
uge aus der logischen Werkzeugebene des Informationssystems des UKL
132
9.3 Anforderungsdom¨
anen
Elemente
Hinweise
logische Werkzeugebene (Fortsetzung)
Anwendungsbaustein Verschl¨
usselungssystem
zentrales Werkzeug f¨
ur die Aufgabe Diagnosen- und Prozedurenverschl¨
usselung am UKL; Master-Anwendungsbaustein
f¨
ur diese Aufgabe und f¨
ur die Begriffssysteme ICD10 und
OPS301.
→ stellt u
¨ ber eine Bausteinschnittstelle bereit:
Operation DiaProz Verschl
Anwendungsbausteine
Laborinformationssystem,
Radiologieinformationssystem,
Bild- und Befundserver,
MCC-basiertes Klinisches Dokumen-,
tations- und Managementsystem
(KDMS-MCC)
erm¨
oglicht die interaktive Verschl¨
usselung von Diagnosen und
Prozeduren und gibt Ergebnisnachrichten mit den verschl¨
usselten Diagnosen und Prozeduren zur¨
uck
Werkzeuge f¨
ur die klinische Informationsverarbeitung am
UKL
mit verschiedenen Teilbausteinen,
z. B. OP-Planungssystem
IS-H*MED-basiertes Klinisches Dokumentations- und Managementsystem
(KDMS-ISH*MED)
→ stellen jeweils u
¨ ber eine Bausteinschnittstelle bereit:
Operation ADT-Nachrichten¨
ubergabe
Anwendungsbaustein Kommunikationsserver
(s. o.)
¨
zentrales Kommunikationswerkzeug f¨
ur die Filterung, Ubersetzung und Weiterleitung von Nachrichten
→ stellt u
¨ ber eine Bausteinschnittstelle bereit:
Operation ADT-Nachrichten¨
ubergabe
(s. o.)
→ kann u
¨ ber mehrere Bausteinschnittstellen aufrufen:
Operation ADT-Nachrichten¨
ubergabe
(s. o.)
¨
Anwendungsbaustein LDAP-Benutzerverzeichzentrales Werkzeug f¨
ur die Uberpr¨
ufung von Zugriffsrechten
nissystem
physische Werkzeugebene
physischer Datenverarbeitungsbaustein PC
ein PC auf einer Station der Klinik f¨
ur Neurochirurgie.
NCH 15
Tabelle 9.2: Elemente des Beispielmodells des Informationssystems des UKL (Fortsetzung 2)
Die Abbildungen geben zun¨
achst einen Eindruck von der Komplexit¨
at des verwendeten Modells und damit auch vom Bedarf an Unterst¨
utzung bei der Bewertung. Die Tabellen 9.1 und 9.2
nennen und beschreiben kurz wesentliche in den Beispielen verwendete Modellelemente. Auf
eine ausf¨
uhrliche tabellarische oder textliche Beschreibung der einzelnen Kommunikationsver¨
bindungen wurde hier zugunsten der Ubersichtlichkeit
verzichtet. Bei den einzelnen Beispielen
werden Hinweise zu den realisierten Kommunikationsverbindungen gegeben.
9.3 Anforderungsdom¨
anen
9.3.1 Datendom¨
anen
Eine Menge von Anwendungsbausteinen, f¨
ur die die Forderung nach Datenintegration besteht, wird hier als Datendom¨
ane bezeichnet (vgl. Abschnitt 2.2.2). Datenintegration muss
zwischen Anwendungsbausteinen hergestellt werden, die dieselben Informationen verarbeiten.
Damit wird eine mehrfache u. U. aufwendige und fehleranf¨
allige Erfassung von Daten, die die
betreffenden Informationen repr¨
asentieren, vermieden.
Im Folgenden wird eine formale Definition f¨
ur die Bestimmung von Datendom¨
anen angege-
133
9 Die Erf¨
ullung von Integrationsanforderungen
Abbildung 9.3: Datendom¨
ane des Objekttyps Fall
ben. Die Definition sieht vor, dass eine Datendom¨
ane jeweils f¨
ur einen Objekttyp bestimmt
wird.
Definition 9.1 Die Datendom¨
ane eines Objekttyps objt ist die Menge aller Anwendungsbausteine awbi , die objt ben¨
otigen.
DDom(objt, ergt)
:=
{awbi ∈ AWB | benoetigt(awbi , ergt, objt)}
(9.1)
Ende — Definition und Berechnungsvorschrift
Abbildung 9.3 zeigt ein Beispiel f¨
ur eine Datendom¨
ane. Das Beispiel geht, auf der Basis der
Szenariobeschreibung in Abschnitt 9.2, davon aus, dass alle der hervorgehobenen Anwendungsbausteine Aufgaben unterst¨
utzen, die auf den Objekttyp Fall zugreifen.
9.3.2 Funktionale Dom¨
anen
Eine Menge von Anwendungsbausteinen, f¨
ur die die Forderung nach funktionaler Integration
besteht, wird hier als funktionale Dom¨
ane bezeichnet (vgl. Abschnitt 2.2.3). Das Ben¨
otigen einer Funktion in mehreren Anwendungssystemen im Sinne der Definition 2.3 in Abschnitt 2.2.3
uckt, dass mehrere Anwendungsbausteine
wird auf der Basis des 3LGM2A dadurch ausgedr¨
134
9.3 Anforderungsdom¨
anen
Abbildung 9.4: Funktionale Dom¨
ane der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung
dieselbe Aufgabe unterst¨
utzen. Das Unterst¨
utzen einer Aufgabe durch einen Anwendungsbaustein wird entsprechend dem Pr¨
adikat unterstuetzt (vgl. Definitionsgleichung 8.36) durch
gemeinsame Nutzung verschiedener Assoziationsbeziehungen, z. B. wird_erledigt_in und
mit_Hilfe_von, modelliert.
In den meisten F¨
allen wird eine mehrfach ben¨
otigte bzw. unterst¨
utzte Funktionalit¨
at, d. h.
eine bestimmte Aufgabe, Teil anderer Funktionalit¨
aten, d. h. anderer Aufgaben, sein. Beispiele
sind die Aufgabe Laborbefund pr¨
asentieren als Teil der Aufgaben Chemotherapie planen und
Entlassung vorbereiten sowie die Aufgabe Verschl¨
usseln von Diagnosen und Prozeduren als Teil
der Aufgaben Arztbriefschreibung, OP-Dokumentation und station¨
are Leistungsdokumentation.
Durch die in Abschnitt 8.2 definierte Interpretationsregel f¨
ur Elementhierarchien folgt aus
dem Unterst¨
utzen einer u
¨ bergeordneten Aufgabe durch einen Anwendungsbaustein auch das
Unterst¨
utzen der Teilaufgaben.
Funktionale Integration muss also zwischen den Anwendungsbausteinen hergestellt werden,
die dieselbe(n) Aufgabe(n) unterst¨
utzen.
Definition 9.2 Die funktionale Dom¨
ane einer Aufgabe auf ist die Menge aller Anwendungsbausteine awbi , die auf unterst¨
utzen.
FDom(auf )
:=
{ awbi ∈ AWB | unterstuetzt(awbi , auf ) }
(9.2)
135
9 Die Erf¨
ullung von Integrationsanforderungen
Ende — Definition und Berechnungsvorschrift
Abbildung 9.4 zeigt ein Beispiel f¨
ur eine funktionale Dom¨
ane. Das Beispiel geht, auf der Basis der Szenariobeschreibung in Abschnitt 9.2, davon aus, dass alle der hervorgehobenen Anwendungsbausteine Aufgaben unterst¨
utzen, der als Teilaufgabe die Aufgabe Diagnosen- und
Prozedurenverschl¨
usselung untergeordnet ist.
9.3.3 Semantische Dom¨
anen
Eine Menge von Anwendungsbausteinen, f¨
ur die die Forderung nach semantischer Integration besteht, wird hier als semantische Dom¨
ane bezeichnet (vgl. Abschnitt 2.2.4). Semantische
Integration muss zwischen den Anwendungsbausteinen hergestellt werden, bei denen Daten
mit Hilfe derselben Begriffssysteme interpretiert werden (vgl. auch Exkurs Semantische Inte”
gration“ in Abschnitt 2.2.4). Dazu wurde in Abschnitt 7.7 die Klasse Begriffssystem in das
uhrt.
3LGM2A eingef¨
Semantische Dom¨
anen werden auf der Basis von Datendom¨
anen und des in Abschnitt 8.5.2
definierten Pr¨
adikates wird_angewendet_auf definiert:
Definition 9.3 Die semantische Dom¨
ane eines Begriffssystems bgs ist die Vereinigung
der Datendom¨
anen aller Objekttypen, auf die bgs angewendet wird.
SDom(bgs)
:=
[
DDom(objti ) | wird_angewendet_auf(bgs, objti )
(9.3)
i=0...OBJT
Ende — Definition und Berechnungsvorschrift
Abbildung 9.5 zeigt ein Beispiel f¨
ur Begriffssysteme auf der fachlichen Ebene und die zugeh¨
origen semantischen Dom¨
anen. Das Beispiel geht, auf der Basis der Szenariobeschreibung
in Abschnitt 9.2, davon aus, dass alle der hervorgehobenen Anwendungsbausteine Aufgaben unterst¨
utzen, die auf die Objekttypen Diagnose und Prozedur zugreifen und dabei die
Begriffssysteme ICD10, OPS301 und DRG ber¨
ucksichtigen.
9.3.4 Kontextdom¨
anen
Eine Menge von Anwendungsbausteinen, f¨
ur die die Forderung nach Kontextintegration besteht, wird hier als Kontextdom¨
ane bezeichnet (vgl. Abschnitt 2.2.5). Kontextintegration muss
z. B. f¨
ur Anwendungsbausteine hergestellt werden, die gleichzeitig durch bestimmte Personen an einem oder mehreren physischen Datenverarbeitungsbausteinen genutzt werden
(Personenkontext).
Herstellen von Kontextintegration bedeutet, dass Anwendungsbausteine hinsichtlich einer
bestimmten Information, d. h. der Auspr¨
agung eines Objekttyps, f¨
ur eine bestimmte Zeit synchronisiert werden. Die Information legt einen Arbeitsrahmen fest, der als Kontext bezeichnet
wird: Benutzerkontext, Patientenkontext usw.
Damit k¨
onnen Kontextdom¨
anen, ausgehend von Objekttypen und physischen Datenverarbeitungsbausteinen, genauer definiert werden:
136
9.3 Anforderungsdom¨
anen
a)
b)
Abbildung 9.5: Zuordnung der Begriffssysteme DRG, ICD10 und OPS301 zu greift_zu_auf-Beziehungen (a) und
semantische Dom¨
anen der Begriffssysteme (b)
Definition 9.4 Die Kontextdom¨
ane eines Objekttyps objt und eines physischen Datenverarbeitungsbausteines pdvb ist die Datendom¨
ane von objt, eingeschr¨
ankt auf diejenigen
Anwendungsbausteine, die gemeinsam auf pdvb installiert sind:
benoetigt(awbi , objt)
∧
awbi ∈ AWB ist_installiert_auf(awbi , pdvb)
KDom(objt, pdvb)
:=
(9.4)
Werden mehrere physische Datenverarbeitungsbausteine gemeinsam genutzt, muss die
Vereinigung der einzelnen Kontextdom¨
anen gebildet werden.
137
9 Die Erf¨
ullung von Integrationsanforderungen
Abbildung 9.6: Kontextdom¨
ane des Objekttyps Fall und des physischen Datenverarbeitungsbausteines PC NCH 15
Ende — Definition und Berechnungsvorschrift
In der Praxis werden i. d. R. nur die Teilanwendungsbausteine der betreffenden Anwendungsbausteine auf dem genannten PC installiert sein, mit denen auf zentrale ServerAnwendungsbausteine zugegriffen wird.
Abbildung 9.6 zeigt ein Beispiel f¨
ur eine Kontextdom¨
ane. Das Beispiel geht, auf der Basis der
Szenariobeschreibung in Abschnitt 9.2, davon aus, dass alle der hervorgehobenen Anwendungsbausteine hinsichtlich des Objekttyps Fall synchronisiert werden sollen sowie gemeinsam auf
dem physischen Datenverarbeitungsbaustein PC NCH 15 installiert sind und gemeinsam
genutzt werden.
9.3.5 Pr¨
asentationsdom¨
anen
Eine Menge von Anwendungsbausteinen, f¨
ur die die Forderung nach Pr¨
asentationsintegration
besteht, wird hier als Pr¨
asentationsdom¨
ane bezeichnet (vgl. Abschnitt 2.2.6). Wie Kontextintegration muss Pr¨
asentationsintegration f¨
ur Anwendungsbausteine hergestellt werden, die
gleichzeitig durch bestimmte Personen an einem oder mehreren physischen Datenverarbeitungsbausteinen genutzt werden.
Bei der Pr¨
asentationsintegration f¨
allt, im Vergleich zu Kontextdom¨
anen, der Bezug zu Ob-
138
9.3 Anforderungsdom¨
anen
Abbildung 9.7: Pr¨
asentationsdom¨
ane des physischen Datenverarbeitungsbausteines PC NCH 15
jekttypen weg, da sie unabh¨
angig von den verarbeiteten Informationen hergestellt werden
sollte bzw. muss. Gleiches gilt f¨
ur den Bezug zu Ereignistypen. Die Menge der Anwendungsbausteine, f¨
ur die Pr¨
asentationsintegration herzustellen ist, wird also durch einen physischen
Datenverarbeitungsbaustein bestimmt.
Damit k¨
onnen Pr¨
asentationsdom¨
anen, ausgehend von physischen Datenverarbeitungsbausteinen, genauer definiert werden:
Definition 9.5 Die Pr¨
asentationsdom¨
ane eines physischen Datenverarbeitungsbausteines pdvb ist die Menge aller Anwendungsbausteine awbi , die gemeinsam auf pdvb installiert
sind:
PDom(pdvb)
:=
{awbi ∈ AWB | ist_installiert_auf(awb, pdvb) }
(9.5)
Werden mehrere physische Datenverarbeitungsbausteine gemeinsam genutzt, muss die
Vereinigung der einzelnen Pr¨
asentationsdom¨
anen gebildet werden.
Ende — Definition und Berechnungsvorschrift
Abbildung 9.7 zeigt ein Beispiel f¨
ur eine Pr¨
asentationsdom¨
ane. Das Beispiel geht, auf der
Basis der Szenariobeschreibung in Abschnitt 9.2, davon aus, dass alle der hervorgehobenen
139
9 Die Erf¨
ullung von Integrationsanforderungen
Anwendungsbausteine gemeinsam auf dem physischen Datenverarbeitungsbaustein PC
NCH 15 installiert sind und gemeinsam genutzt werden.
9.3.6 Zugriffsdom¨
anen
Eine Menge von Anwendungsbausteinen, f¨
ur die die Forderung nach Zugriffsintegration besteht, wird hier als Zugriffsdom¨
ane bezeichnet (vgl. Abschnitt 2.2.7). Zugriffsintegration muss,
ahnlich der Pr¨
asentationsintegration, zwischen den Anwendungsbausteinen hergestellt werden,
¨
an denen dieselben Personen arbeiten. Wie bei Kontextdom¨
anen und Pr¨
asentationsdom¨
anen
wird dieser Sachverhalt u
¨ ber den Bezug zu physischen Datenverarbeitungsbausteinen ausgedr¨
uckt; auch hier f¨
allt, im Vergleich zu Kontextdom¨
anen, der Bezug zu Objekttypen und
Ereignistypen weg.
Zugriffsdom¨
anen werden also wie Pr¨
asentationsdom¨
anen definiert:
Definition 9.6 Die Zugriffsdom¨
ane eines physischen Datenverarbeitungsbausteines pdvb
ist die Menge aller Anwendungsbausteine awbi , die gemeinsam auf pdvb installiert sind:
ZDom(pdvb)
:=
{awbi ∈ AWB | ist_installiert_auf(awb, pdvb) }
(9.6)
Werden mehrere physische Datenverarbeitungsbausteine durch dieselben Personen genutzt, muss die Vereinigung der einzelnen Zugriffsdom¨
anen gebildet werden.
Ende — Definition und Berechnungsvorschrift
Alternative Modellierung von Zugriffsdom¨
anen
Alternativ zur beschriebenen Berechnung von Zugriffsdom¨
anen kann folgendes Verfahren angewendet werden: Personeninformationen k¨
onnen u
ber
spezielle
Objekttypen, z. B. Labormitar¨
beiter, modelliert werden, die denjenigen Aufgaben zugeordnet sind, die von den betreffenden
Personen bearbeitet werden. Dann k¨
onnen Zugriffsdom¨
anen einfach als Datendom¨
anen dieser
Objekttypen modelliert werden.
9.4 Kommunikationsdom¨
anen
Kommunikationsdom¨
anen sind Mengen von Anwendungsbausteinen, bei denen durch Einrichtung von Kommunikationsverbindungen ein bestimmter Integrationsstatus hergestellt wurde.
Es spielt dabei zun¨
achst keine Rolle, mit welchen Integrationstechniken, d. h. u
¨ ber welche Arten
von Middleware, die Integration hergestellt wurde. Die Tatsache, dass Integration hergestellt
wurde, wird hier auf die Feststellung reduziert, dass durch Operationsaufrufe mit bestimmten
Parametern Kommunikationspfade zwischen Anwendungsbausteinen existieren.
¨
9.4.1 Dom¨
anen f¨
ur die Ubermittlung
von Informationen
¨
Ubermittlungsdom¨
anen f¨
ur Objekttypen und Begriffssysteme enthalten Anwendungsbausteine, zu denen Informationen u
¨ bermittelt werden.
¨
Definition 9.7 Die Ubermittlungssdom
ane eines Objekttyps objt, eines Ereignistyps
¨
ergt und eines Anwendungsbausteines awb enth¨
alt die Anwendungsbausteine, zu denen objt
140
9.4 Kommunikationsdom¨
anen
¨
Abbildung 9.8: Ubermittlungsdom¨
ane des Objekttyps Fall, des Ereignistyps NP11I0 und des Anwendungsbausteines
Patientenverwaltungssystem
bei Eintreten von ergt von awb aus u
ur den Austausch von Objekttypen
¨ bermittelt wird. F¨
ist es dabei erforderlich, dass die betreffenden Objekttypen in mindestens einem Anwendungsbaustein gespeichert sind, ihrem Master-Anwendungsbaustein.
8
<
UebDom(objt, ergt, awb)
:=
awbi ∈ AWB
:
9
hat_als_Master(objt, awb)
∧=
wird_gespeichert_in(objt, awb)
∧
wird_uebermittelt(objt, ergt, awb, awbi ) ;
(9.7)
Ende — Definition und Berechnungsvorschrift
Insbesondere bei der Betrachtung der Kommunikation wird die Bedeutung der transitiven
Auswertung des Pr¨
adikates wird_uebermittelt deutlich (vgl. Abschnitt 8.5.3). Dadurch k¨
onnen Kommunikationsverbindungen, die aus mehreren einzelnen Kommunikationsbeziehungen
zusammengesetzt sind, ber¨
ucksichtigt werden (vgl. Abschnitt 8.6.1).
¨
Abbildung 9.8 zeigt ein Beispiel f¨
ur eine Ubermittlungsdom¨
ane eines Objekttyps. Das Beispiel geht, auf der Basis der Szenariobeschreibung in Abschnitt 9.2, davon aus, dass zu allen der hervorgehobenen Anwendungsbausteine, ausgehend vom Patientenverwaltungssystem
beim Eintreten des Ereignistyps NP11I0, Nachrichtentypen u
¨ bermittelt werden, die den Objekttyp Fall repr¨
asentieren.
141
9 Die Erf¨
ullung von Integrationsanforderungen
Abbildung 9.9: Aufrufdom¨
ane der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung, des Ereignistyps DIAusselungssystem
PROZ init und des Anwendungsbausteines Verschl¨
Auf der Basis der Ausf¨
uhrungen in Abschnitt 8.5.3 k¨
onnen, wie f¨
ur Objekttypen, auch f¨
ur
¨
Begriffssysteme Ubermittlungsdom¨
anen bestimmt werden:
¨
Definition 9.8 Die Ubermittlungssdom
ane eines Begriffssystems bgs, eines Ereignis¨
typs ergt und eines Anwendungsbausteines awb enth¨
alt die Anwendungsbausteine, zu denen
bgs bei Eintreten von ergt von awb aus u
¨ bermittelt wird.
8
<
UebDomB(bgs, ergt, awb)
:=
awbi ∈ AWB
:
9
hat_als_Master(bgs, awb)
∧=
wird_gespeichert_in(bgs, awb)
∧
wird_uebermittelt_b(bgs, ergt, awb, awbi ) ;
(9.8)
Ende — Definition und Berechnungsvorschrift
9.4.2 Dom¨
anen f¨
ur den Aufruf von Funktionalit¨
at
Aufrufdom¨
anen f¨
ur Aufgaben enthalten Anwendungsbausteine, die Funktionalit¨
at zur Erf¨
ullung bestimmter Aufgaben von anderen Anwendungsbausteinen aufrufen.
Definition 9.9 Die Aufrufdom¨
ane einer Aufgabe auf , eines Ereignistyps ergt und eines
Anwendungsbausteines awb enth¨
alt die Anwendungsbausteine, die Funktionalit¨
at zur Erf¨
ul-
142
9.5 Anwendung: Pr¨
ufung der Erf¨
ullung von Integrationsanforderungen
Kasten 9.1: Ereignistypen und Kommunikationsdom¨
anen
Durch die Ber¨
ucksichtigung von Ereignistypen bei der Bestimmung von Kommunikationsdom¨
anen kann analysiert
¨
werden, ob bestimmte Ubermittlungen
von Objekttypen oder bestimmte Aufrufe von Aufgaben bei allen oder nur
¨
einzelnen relevanten Ereignistypen stattfinden. Damit kann beispielsweise festgestellt werden, ob die Ubermittlung
von Falldaten beim Eintreten aller Ereignistypen, die bei einer Bearbeitung des Objekttyps Fall ausgel¨
ost werden,
erfolgt, oder nur beim Eintreten einzelner dieser Ereignistypen.
¨
Zur vollst¨
andigen Realisierung von Datenintegration f¨
ur einen bestimmten Objekttyp geh¨
ort u. a. auch die Ubermittlung beim Eintreten aller relevanter Ereignistypen. Diese bedingung ist in der Praxis oft nicht erf¨
ullt.
lung von auf bei Eintreten von ergt von awb aufrufen.
AufDom(auf, ergt, awb)
:=
awbi ∈ AWB
unterstuetzt(awb, auf )
∧
ruft_auf(auf, ergt, awbi , awb)
(9.9)
Ende — Definition und Berechnungsvorschrift
Abbildung 9.9 zeigt ein Beispiel f¨
ur eine Aufrufdom¨
ane einer Aufgabe. Das Beispiel geht, auf
der Basis der Szenariobeschreibung in Abschnitt 9.2, davon aus, dass alle der hervorgehobenen Anwendungsbausteine beim Eintreten des Ereignistyps DIAPROZ init die Operation
DiaProz Verschl aufrufen, die das Verschl¨
usselungssystem u
¨ ber eine Bausteinschnittstelle
bereitstellt.
9.5 Anwendung: Pr¨
ufung der Erf¨
ullung von Integrationsanforderungen
Die in den vorhergehenden Abschnitten definierten Dom¨
anentypen k¨
onnen f¨
ur eine Bewertung
der Integration genutzt werden. Durch den Vergleich von Anforderungsdom¨
anen mit Kommunikationsdom¨
anen kann festgestellt werden, ob Integrationsanforderungen erf¨
ullt sind.
9.5.1 Pr¨
ufung auf realisierte Datenintegration
Die Erf¨
ullung der Forderung nach Datenintegration bestimmter Anwendungsbausteine erfolgt
¨
durch Vergleich der Datendom¨
ane des interessierenden Objekttyps mit den Ubermittlungsdom¨anen dieses Objekttyps.
Die Forderung nach Datenintegration
– bzgl. eines Objekttyps objt
ist genau dann erf¨
ullt, wenn
– f¨
ur alle Ereignistypen ergti , die zu einer Bearbeitung von objt f¨
uhren, und
– f¨
ur alle Master-Anwendungsbausteinene awbj von objt
¨
die Datendom¨
ane von objt Teilmenge jeder Ubermittlungsdom¨
ane von objt ist. Der Ausdruck
∀ergti ∈ ERGT∗ ,awbj ∈ AWB∗ : DDom(objt, ergti ) ⊆ UebDom(objt, ergti , awbj )
ERGT∗ = Menge der ergti , die zu einer Bearbeitung von objt f¨
uhren
ur objt sind
AWB∗ = Menge der awbj , die Master-Anwendungsbaustein f¨
(9.10)
muss also f¨
ur den betreffenden Objekttyp wahr sein.
143
9 Die Erf¨
ullung von Integrationsanforderungen
a)
b)
¨
Abbildung 9.10: Vergleich der Datendom¨
ane des Objekttyps Fall und des Ereignistyps NP11I0 (a) mit der Ubermittlungsdom¨
ane des Objekttyps Fall, des Ereignistyps NP11I0 und des Anwendungsbausteines Patientenverwaltungssystem
(b)
144
9.5 Anwendung: Pr¨
ufung der Erf¨
ullung von Integrationsanforderungen
Ein Vergleich der Datendom¨
ane des Objekttyps Fall und des Ereignistyps NP11I0 in
¨
der Beispielabbildung 9.3 mit der Ubermittlungsdom¨
ane desselben Objekttyps und desselben Ereignistyps sowie des Anwendungsbausteines Patientenverwaltungssystem in der Beispielabbildung 9.8 zeigt, dass die in der Datendom¨
ane enthaltenen Anwendungsbausteine Radiologieinformationssystem RAD und Endoskopie-/Sonographiedokumentationssystem nicht in
¨
der Ubermittlungsdom¨
ane enthalten sind (Abbildung 9.10). In diesem Beispiel ist die Forderung nach Datenintegration hinsichtlich des Objekttyps Fall zun¨
achst nicht vollst¨
andig erf¨
ullt. Es sei gegeben, dass f¨
ur den Objekttyp Fall, den Ereignistyp RIS Fall Abfrage und
¨
den Anwendungsbaustein RIS Kommunikationsmodul eine weitere Ubermittlungsdom¨
ane existiert, die das Radiologieinformationssystem RAD enth¨
alt. Damit wird die fehlende unmittel¨
bare Mitgliedschaft in der urspr¨
unglichen Ubermittlungsdom¨
ane ausgeglichen. Auch f¨
ur das
¨
Endoskopie-/Sonographiedokumentationssystem sei hier die Existenz einer zus¨
atzlichen Ubermittlungsdom¨
ane mit dem MCC-basierten Klinischen Dokumentations- und Managementsystem angenommen.
9.5.2 Pr¨
ufung auf realisierte funktionale Integration
Die Erf¨
ullung der Forderung nach funktionaler Integration erfolgt durch Vergleich der funktionalen Dom¨
ane der interessierenden Aufgabe mit den Aufrufdom¨
anen dieser Aufgabe.
Die Forderung nach funktionaler Integration
– bzgl. einer Aufgabe auf
ist genau dann erf¨
ullt, wenn
– f¨
ur alle Ereignistypen ergti , die zu einer Aktivit¨
at von auf f¨
uhren, und
– f¨
ur alle Master-Anwendungsbausteine awbj von auf
die funktionale Dom¨
ane von auf Teilmenge jeder Aufrufdom¨
ane von auf ist. Der Ausdruck
∀ergti ∈ ERGT∗ ,awbj ∈ AWB∗ : FDom(auf ) ⊆ AufDom(auf, ergti , awbj )
ERGT∗ = Menge der ergti , die zu einer Aktivit¨
at von auf f¨
uhren
ur auf sind
AWB∗ = Menge der awbj , die Master-Anwendungsbaustein f¨
(9.11)
muss also f¨
ur die betreffende Aufgabe wahr sein.
Bei der Pr¨
ufung wird auch die M¨
oglichkeit ber¨
ucksichtigt, dass mehrere Master-Anwendungsbausteine f¨
ur die betrachtete Aufgabe existieren. Diese M¨
oglichkeit steht prinzipiell
im Widerspruch zur Idee der funktionalen Integration. Sie wird hier trotzdem einger¨
aumt, da
die praktische Umsetzung u. U. eine zentrale aber trotzdem redundante Bereitstellung einer
bestimmten Funktionalit¨
at erfordern kann.
Ein Vergleich der funktionalen Dom¨
ane der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung mit der Aufrufdom¨
ane der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung, des
Ereignistyps DIAPROZ init und des Anwendungsbausteines Verschl¨
usselungssystem zeigt,
dass nur einige Anwendungsbausteine der funktionalen Dom¨
ane in der Aufrufdom¨
ane enthalten sind (Abbildung 9.11). In diesem Beispiel ist die Forderung nach funktionaler Integration
hinsichtlich der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung nicht bzw. nur teilweise
erf¨
ullt.
145
9 Die Erf¨
ullung von Integrationsanforderungen
a)
b)
Abbildung 9.11: Vergleich der funktionalen Dom¨
ane der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung (a) mit
der Aufrufdom¨
ane der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung, des Ereignistyps DIAPROZ init und des
Anwendungsbausteines Verschl¨
usselungssystem (b)
146
9.5 Anwendung: Pr¨
ufung der Erf¨
ullung von Integrationsanforderungen
9.5.3 Pr¨
ufung auf realisierte semantische Integration
Semantische Integration kann, abh¨
angig davon, ob Begriffssysteme autonom oder zentral
verwaltet werden, u
¨ ber Datenintegration oder u
¨ ber funktionale Integration realisiert werden.
Semantische Integration bei autonomer Begriffssystemverwaltung
Speichern die Anwendungsbausteine einer semantischen Dom¨
ane die verwendeten Begriffssysteme selbst, dann muss zwischen diesen Anwendungsbausteinen Datenintegration hinsichtlich der Begriffssysteme realisiert werden. Durch Vergleich der interessierenden semantischen
¨
Dom¨
anen mit den Ubermittlungsdom¨
anen der betreffenden Begriffssysteme kann dann eine
Pr¨
ufung auf Realisierung der semantischen Integration vorgenommen werden.
Bei autonomer Begriffssystemverwaltung ist die Forderung nach semantischer Integration
– bzgl. eines Begriffssystems bgs
genau dann erf¨
ullt, wenn
– f¨
ur alle Ereignistypen ergti , die zu einer Aktualisierung von bgs f¨
uhren, und
– f¨
ur alle Master-Anwendungsbausteinen awbj von bgs
¨
die semantische Dom¨
ane von bgs Teilmenge jeder Ubermittlungsdom¨
ane von bgs, ergti und
awbj ist. Der Ausdruck
∀ergti ∈ ERGT∗ ,awbj ∈ AWB∗ : SDom(bgs) ⊆ UebDomB(bgs, ergti , awbj )
ERGT∗ = Menge der ergti , die zu einer Aktualisierung von bgs f¨
uhren
ur bgs sind
AWB∗ = Menge der awbj , die Master-Anwendungsbaustein f¨
(9.12)
muss also f¨
ur das betreffende Begriffssystem wahr sein.
¨
Ein Vergleich der semantischen Dom¨
ane des Begriffssystems ICD10 mit der Ubermittlungsdom¨
ane desselben Begriffssystems, des Ereignistyps ICD neu und seines MasterAnwendungsbausteines Verschl¨
usselungssystem zeigt, dass ICD10 zu keinem der Anwendungsbausteine kommuniziert wird, die es ben¨otigen (Abbildung 9.12). In diesem Beispiel ist die
Forderung nach semantischer Integration NICHT erf¨
ullt.
Semantische Integration bei zentraler Begriffssystemverwaltung
Wird ein zentraler Anwendungsbaustein f¨
ur die Bereitstellung bestimmter Begriffssysteme
genutzt, dann muss funktionale Integration hinsichtlich der Aufgabe, die die betreffenden Begriffssysteme nutzt, hergestellt werden. Durch Vergleich der interessierenden semantischen
Dom¨
anen mit den Aufrufdom¨
anen der betreffenden Aufgabe kann eine Pr¨
ufung auf Realisierung der semantischen Integration vorgenommen werden.
Bei zentraler Begriffssystemverwaltung ist die Forderung nach semantischer Integration
– bzgl. einer Aufgabe auf , die f¨
ur die Aufgabe des Begriffssystemzugriffs steht, und
– bzgl. eines Begriffssystems bgs
genau dann erf¨
ullt, wenn
– f¨
ur alle Ereignistypen ergti , die zu einer Aktivit¨
at von auf f¨
uhren, und
– f¨
ur alle Master-Anwendungsbausteine awbj von auf
147
9 Die Erf¨
ullung von Integrationsanforderungen
a)
b)
¨
Abbildung 9.12: Vergleich der semantischen Dom¨
ane des Begriffssystems ICD10 (a) mit der Ubermittlungsdom¨
ane
desselben Begriffssystems, des Ereignistyps ICD neu und des Anwendungsbausteines Verschl¨
usselungssystem (b)
148
9.5 Anwendung: Pr¨
ufung der Erf¨
ullung von Integrationsanforderungen
a)
b)
Abbildung 9.13: Vergleich der semantischen Dom¨
ane des Begriffssystems ICD10 (a) mit der Aufrufdom¨
ane der Aufgabe
Diagnosen- und Prozedurenverschl¨
usselung, des Ereignistyps DIAPROZ init und des Anwendungsbausteines Verschl¨
usselungssystem (b)
149
9 Die Erf¨
ullung von Integrationsanforderungen
die semantische Dom¨
ane von bgs Teilmenge jeder Aufrufdom¨
ane von auf ist. Der Ausdruck
∀ergti ∈ ERGT∗ ,awbj ∈ AWB∗ : SDom(bgs) ⊆ AufDom(auf, ergti , awbj )
ERGT∗ = Menge der ergti , die zu einer Aktivit¨
at von auf f¨
uhren
ur auf sind
AWB∗ = Menge der awbj , die Master-Anwendungsbaustein f¨
(9.13)
muss also f¨
ur die betreffende Aufgabe und f¨
ur das betreffende Begriffssystem wahr sein.
Ein Vergleich der semantischen Dom¨
ane des Begriffssystems ICD10 mit der Aufrufdom¨
ane der Aufgabe Diagnosen- und Prozedurenverschl¨
usselung, des Ereignistyps DIAPROZ init
und des Anwendungsbausteines Verschl¨
usselungssystem zeigt, dass einige, aber nicht alle,
Anwendungsbausteine der semantischen Dom¨
ane auch Elemente der Aufrufdom¨
ane sind (Abbildung 9.13). Die Forderung nach semantischer Integration ist in diesem Beispiel nicht bzw.
nur teilweise erf¨
ullt. Im Vergleich zum vorhergehenden Beispiel zur autonomen Begriffssystemverwaltung ist jedoch mehr“ semantische Integration realisiert.
”
9.5.4 Pr¨
ufung auf realisierte Kontextintegration
Die Erf¨
ullung der Forderung nach Kontextintegration erfolgt durch Vergleich der Kontextdom¨
ane des interessierenden Objekttyps, des interessierenden physischen Datenverarbeitungsbausteines und der Ereignistypen, die eine Kontextsynchronisierung erfordern, mit
¨
den Ubermittlungsdom¨
anen des Objekttyps sowie eines speziellen Objekttyps f¨
ur Informationen zur Identifikation von physischen Datenverarbeitungsbausteinen und der genannten
Ereignistypen. Der spezielle Objekttyp ist zus¨
atzlich zu modellieren und wird ben¨
otigt, da
auch Daten zum betroffenen physischen Datenverarbeitungsbaustein u
¨ bermittelt werden
m¨
ussen.
Die Forderung nach Kontextintegration
– bzgl. eines Objekttyps objt und
– bzgl. eines physischen Datenverarbeitungsbausteines pdvb
ist genau dann erf¨
ullt, wenn
– f¨
ur alle Ereignistypen ergti , die eine Kontextsynchronisierung erfordern, und
– f¨
ur alle Anwendungsbausteine awbj , die einen Kontextwechsel ausl¨
osen,
¨
die Kontextdom¨
ane von objt, pdvb Teilmenge jeder Ubermittlungsdom¨
ane von objt und dem
speziellen Objekttyp objt∗ ist. Der Ausdruck
∀ergti ∈ ERGT∗ ,awbj ∈ AWB∗ : KDom(objt, pdvb, ergti ) ⊆
(UebDom(objt,
ergti , awbj )
S
UebDom(objt∗, ergti , awbj ))
ERGT∗ = Menge der ergti , die einen Kontextwechsel bzgl. objt erfordern
osen
AWB∗ = Menge der awbj , die einen Kontextwechsel bzgl. objt ausl¨
objt∗ = Objekttyp f¨
ur Informationen zur Identifikation von physischen
Datenverarbeitungsbausteinen
(9.14)
muss also f¨
ur den betreffenden Objekttyp und den betreffenden physischen Datenverarbeitungsbaustein wahr sein.
Ein Vergleich der Kontextdom¨ane des Objekttyps Fall und des Ereignistyps Kontextwech¨
sel Fall mit der Ubermittlungsdom¨
ane desselben Objekttyps und desselben Ereignistyps
sowie des Anwendungsbausteines KDMS-IS-H*MED zeigt, dass der in der Kontextdom¨
ane
150
9.5 Anwendung: Pr¨
ufung der Erf¨
ullung von Integrationsanforderungen
a)
b)
Abbildung 9.14: Vergleich der Kontextdom¨
ane des Objekttyps Fall, des physischen Datenverarbeitungsbausteines
¨
PC NCH 15 und des Ereignistyps Kontextwechsel Fall (a) mit der Ubermittlungsdom¨
ane des Objekttyps Fall, des
Ereignistyps Kontextwechsel Fall und des Anwendungsbausteines KDMS-IS-H*MED (b)
151
9 Die Erf¨
ullung von Integrationsanforderungen
¨
enthaltene Anwendungsbaustein Bild- und Befundserver nicht in der Ubermittlungsdom¨
ane
enthalten ist (Abbildung 9.14). In diesem Beispiel ist die Forderung nach Kontextintegration
hinsichtlich des Objekttyps Fall NICHT erf¨
ullt.
9.5.5 Pr¨
ufung auf realisierte Pr¨
asentationsintegration
Die Pr¨
ufung auf Pr¨
asentationsintegration kann, im Gegensatz zu den anderen Integrationspr¨
ufungen, nicht unmittelbar durch Vergleich von Anforderungsdom¨
anen mit Kommunikationsdom¨
anen vorgenommen werden. Das ist insofern folgerichtig, als die gleiche Gestaltung von
Benutzungsschnittstellen unterschiedlicher Anwendungsbausteine nicht unmittelbar mit
der Kommunikation von Daten oder Funktionalit¨
at zusammenh¨
angt.
Aus dem Vorliegen von funktionaler Integration bez¨
uglich bestimmter Aufgaben kann u. U.
das Vorliegen von Pr¨
asentationsintegration abgeleitet werden. Das gilt, wenn die betreffenden
Aufgaben mit Dateneingabe durch einen Benutzer oder mit Datenausgabe verbunden sind.
Wenn mehrere genutzte Anwendungsbausteine denselben Teil-Anwendungsbaustein zur Erf¨
ullung einer Teil-Aufgabe nutzen, dann liegt zumindest f¨
ur die Erledigung dieser Teil-Aufgabe an
dem betreffenden physischen Datenverarbeitungsbaustein Pr¨
asentationsintegration vor.
9.5.6 Pr¨
ufung auf realisierte Zugriffsintegration
Zugriffsintegration kann, abh¨
angig davon, ob Zugriffsinformationen autonom oder zentral verwaltet werden, u
¨ ber Datenintegration oder u
¨ ber funktionale Integration realisiert werden.
Zugriffsintegration bei autonomer Zugriffsverwaltung
F¨
uhren die Anwendungsbausteine einer Zugriffsdom¨
ane jeweils eigene Datenbanksysteme f¨
ur
die Zugriffsverwaltung, dann muss zwischen diesen Anwendungsbausteinen Datenintegration
hinsichtlich der Zugriffsinformationen realisiert werden. Die Zugriffsinformationen m¨
ussen in
diesem Fall u
ur bestimmte Personengruppen modelliert werden,
¨ ber spezielle Objekttypen f¨
z. B. Labormitarbeiter oder Mitarbeiter des Pflegedienstes. Durch Vergleich der interessierenden
¨
Zugriffsdom¨
anen mit den Ubermittlungsdom¨
anen der betreffenden Objekttypen kann dann
eine Pr¨
ufung auf Realisierung der Zugriffsintegration vorgenommen werden.
Bei autonomer Zugriffsverwaltung ist die Forderung nach Zugriffsintegration
– bzgl. eines Objekttyps objt, der f¨
ur Zugriffsinformationen einer bestimmten Personengruppe steht, und
– bzgl. eines physischen Datenverarbeitungsbausteines pdvb, der durch die betreffende
Personengruppe benutzt wird
genau dann erf¨
ullt, wenn
– f¨
ur alle Ereignistypen ergti , die zu einer Bearbeitung von objt f¨
uhren, und
– f¨
ur alle Master-Anwendungsbausteine awbj von objt
¨
die Zugriffsdom¨
ane von pdvb Teilmenge jeder Ubermittlungsdom¨
ane von objt ist. Der Ausdruck
152
9.5 Anwendung: Pr¨
ufung der Erf¨
ullung von Integrationsanforderungen
a)
b)
Abbildung 9.15: Vergleich der Zugriffsdom¨
ane des physischen Datenverarbeitungsbausteines PC NCH 15 (a) mit
¨
der Ubermittlungsdom¨
ane des Objekttyps Mitarbeiter des Pflegedienstes, des Ereignistyps ZUGR update und des
Anwendungsbausteines R/3-basierte Anwendungen (b)
153
9 Die Erf¨
ullung von Integrationsanforderungen
∀ergti ∈ ERGT∗ ,awbj ∈ AWB∗ : ZDom(pdvb) ⊆ UebDom(objt, ergti , awbj )
uhren
ERGT∗ = Menge der ergti , die zu einer Bearbeitung von objt f¨
ur objt sind
AWB∗ = Menge der awbj , die Master-Anwendungsbaustein f¨
(9.15)
muss also f¨
ur den betreffenden Objekttyp und den betreffenden physischen Datenverarbeitungsbaustein wahr sein.
Ein Vergleich der Zugriffsdom¨ane des physischen Datenverarbeitungsbausteines PC N¨
CH 15 mit der Ubermittlungsdom¨
ane des Objekttyps Mitarbeiter des Pflegedienstes, des Ereignistyps ZUGR update und des Anwendungsbausteines R/3-basierte Anwendungen 1 zeigt,
¨
dass der Anwendungsbaustein Bild- und Befundserver nicht in der Ubermittlungsdom¨
ane enthalten ist (Abbildung 9.15). Die Forderung nach Zugriffsintegration ist in diesem Beispiel also
NICHT erf¨
ullt.
Zugriffsintegration bei zentraler Zugriffsverwaltung
Wird in einem zentralen Anwendungsbaustein ein zentrales Datenbanksystem f¨
ur die Zugriffsverwaltung gef¨
uhrt, dann muss funktionale Integration hinsichtlich der Abwicklung von
Zugriffskontrollaktivit¨
aten realisiert werden. In diesem Fall muss eine spezielle Aufgabe f¨
ur die
Zugriffskontrolle modelliert werden, z. B. Rechtepr¨
ufung MRZ. Durch Vergleich der interessierenden Zugriffsdom¨
anen mit den Aufrufdom¨
anen der betreffenden Aufgabe kann dann eine
Pr¨
ufung auf Realisierung der Zugriffsintegration vorgenommen werden.
Bei zentraler Zugriffsverwaltung ist die Forderung nach Zugriffsintegration
– bzgl. einer Aufgabe auf , die f¨
ur die Aufgabe der zentrale Zugriffsverwaltung steht, und
– bzgl. eines physischen Datenverarbeitungsbausteines pdvb, der durch eine bestimmte Personengruppe benutzt wird
genau dann erf¨
ullt, wenn
– f¨
ur alle Ereignistypen ergti , die zu einer Aktivit¨
at von auf f¨
uhren, und
– f¨
ur alle Master-Anwendungsbausteine awbj von auf
die Zugriffsdom¨
ane von pdvb Teilmenge jeder Aufrufdom¨
ane von auf ist. Der Ausdruck
∀ergti ∈ ERGT∗ ,awbj ∈ AWB∗ : ZDom(pdvb) ⊆ AufDom(auf, ergti , awbj )
ERGT∗ = Menge der ergti , die zu einer Aktivit¨
at von auf f¨
uhren
ur auf sind
AWB∗ = Menge der awbj , die Master-Anwendungsbaustein f¨
(9.16)
muss also f¨
ur die betreffende Aufgabe und den betreffenden physischen Datenverarbeitungsbaustein wahr sein.
Ein Vergleich der Zugriffsdom¨
ane des physischen Datenverarbeitungsbausteines PC
NCH 15 mit der Aufrufdom¨
ane der Aufgabe Rechtepr¨
ufung MRZ, des Ereignistyps LOGIN BBS und des Anwendungsbausteines LDAP-Benutzerverzeichnissystem zeigt, dass alle Anwendungsbausteine der Zugriffsdom¨
ane auch Elemente der Aufrufdom¨
ane sind (Abbildung 9.16). Die Forderung nach Zugriffsintegration ist in diesem Beispiel erf¨
ullt. Der Mangel an
Zugriffsintegration u
¨ ber Datenintegration aus dem Beispiel zur autonomen Zugriffsverwaltung
1
Dieser Anwendungsbaustein ist u
¨ bergeordneter Anwendungsbaustein zum in Abschnitt 9.2 genannten KDMSISH*MED.
154
9.5 Anwendung: Pr¨
ufung der Erf¨
ullung von Integrationsanforderungen
a)
b)
Abbildung 9.16: Vergleich der Zugriffsdom¨
ane des physischen Datenverarbeitungsbausteines PC NCH 15 (a) mit
der Aufrufdom¨
ane der Aufgabe Rechtepr¨
ufung MRZ, des Ereignistyps LOGIN BBS und des Anwendungsbausteines
LDAP-Benutzerverzeichnissystem (b)
155
9 Die Erf¨
ullung von Integrationsanforderungen
ist also hier durch zentrale Zugriffsverwaltung mit funktionaler Integration aufgehoben.
156
10 Abh¨
angigkeit von Anwendungsbausteinen
10.1 Vorbemerkungen
Im Zusammenhang mit Datenbanken, insbesondere mit verteilten Datenbanken, wird das in
der Informatik sehr bekannte Transaktionskonzept ausf¨
uhrlich untersucht (siehe z. B. [Vossen
2000], 521-549, [Rahm 1994], S. 111-131). Die damit verbundenen m¨
achtigen Theorien zur
Abwicklung und Absicherung von Transaktionen sollen hier nicht diskutiert werden, jedoch
k¨
onnen einige der damit verbundenen Begriffe helfen, die hier vorgestellten Bewertungsans¨
atze
einzuordnen und zu pr¨
azisieren.
Anwendungsbausteine, die Daten untereinander austauschen, k¨
onnen mit verteilten Datenbanken verglichen werden. Bez¨
uglich der Erf¨
ullung von Integrationsanforderungen sind dabei
vor allem solche Verteilungen von Interesse, bei denen die beteiligten Anwendungsbausteine
keine gemeinsamen Datenbanksysteme haben. Sie lassen sich nach den Einteilungen in [Rahm
1994] oft mit verteilten Transaktionssystemen oder mit f¨
oderativen Datenbanksystemen vergleichen (Abbildung 10.1):
In Mehrrechner-Datenbanksystemen kooperieren mehrere DBVS (bzw. DBVS-Prozesse) zur Bearbeitung
”
von DB-Operationen. Eine verteilte Transaktionsverarbeitung kann jedoch auch außerhalb der DBVS erreicht werden, i.a. unter Kontrolle von TP-Monitoren (. . . ). Wir sprechen in diesem Fall von Verteilten
Transaktionssystemen.“ ([Rahm 1994], Kapitel 11)
F¨
oderative Mehrrechner-DBS (federated database systems) streben nach gr¨
oßerer Knotenautonomie im
”
Vergleich zu den integrierten Systemen, wobei die beteiligten DBVS entweder homogen oder heterogen
sein k¨
onnen. (. . . ) Kennzeichnende Eigenschaft der f¨
oderativen DBS ist, daß jeder Rechner eine eigene
Datenbank verwaltet, die durch ein lokales (privates) konzeptionelles Schema beschrieben ist. Durch eine
begrenzte Kooperation der DBVS soll es m¨
oglich werden, auf bestimmte Daten anderer Rechner zuzugreifen, falls dies von dem Besitzer“ der Daten zugelassen wird. (. . . ) Idealerweise unterst¨
utzen f¨
oderative
”
Mehrrechner-DBS trotz Unterschieden bei den lokalen DBVS ein einheitliches Datenmodell bzw. bieten
eine gemeinsame Anfragesprache nach außen“ an. (. . . )“ ([Rahm 1994], Abschnitt 3.2)
”
Die Verteilung auf unterschiedliche physische Datenverarbeitungsbausteine ist dabei f¨
ur
die hier im Vordergrund stehende Integration von Anwendungssystemen bzw. Anwendungsbausteinen nebens¨
achlich. Wichtiger und hinsichtlich der Erf¨
ullung von Integrationsanforderungen anspruchsvoller ist die Aufteilung auf mehrere Datenbankverwaltungssysteme (DBVS)1 .
Die Einhaltung des ACID-Prinzips f¨
ur Transaktionen (atomicity, consistency, isolation, durability) ist nicht immer f¨
ur alle an einer verteilten Transaktion, d. h. an einer verteilten Datena
unscht. Jedes einzelne der beteiligten Daten¨nderung, beteiligten Anwendungsbausteine erw¨
banksysteme muss selbstverst¨
andlich die Einhaltung f¨
ur sich selbst garantieren. In vielen F¨
allen
wird die Autonomie des eine Transaktion ausl¨
osenden Anwendungsbausteines einer strikten
Einhaltung des ACID-Prinzips vorgezogen. Die Einhaltung ist jedoch dann wichtig, wenn der
ausl¨
osende Anwendungsbaustein NICHT Master-Anwendungsbaustein f¨
ur die von der Transaktion betroffenen Objekttypen ist. In diesem Fall darf die Transaktion im ausl¨
osenden Anwendungsbaustein nur dann ausgef¨
uhrt werden, wenn auch der Master-Anwendungsbaustein
1
Die Feststellung soll keinesfalls die teilweise sehr anspruchsvolle Theorie und praktische Bereitstellung anderer
Datenbankklassen herabsetzen. Die Integration von Anwendungsbausteinen mit integrierten Datenbanksystemen oder mit Datenbanksystemen der Klasse Shared-Everything ist insofern oft einfacher, als die Integration
von den Herstellern mitgeliefert“ wird und nicht erst in speziellen Projekten hergestellt werden muss.
”
157
10 Abh¨
angigkeit von Anwendungsbausteinen
Abbildung 10.1: L¨
osungsspektrum zur Unterst¨
utzung heterogener Datenbanken (Quelle: [Rahm 1994], Abschnitt 10.4)
sie vollst¨
andig ausf¨
uhrt. Eine verz¨
ogerte oder sogar fehlende Ausf¨
uhrung einer Transaktion in
Anwendungsbausteinen, die nicht Master f¨
ur die betroffenen Objekttypen sind, trotzdem aber
zu entsprechenden Datendom¨
anen geh¨
oren, wird oft in Kauf genommen.
Der soeben ausgef¨
uhrte Gedanke l¨
asst sich mit Hilfe des Konzeptes der Master-Anwendungsbausteine (vgl. Abschnitt 6.3.1) folgendermaßen zusammenfassen: Die Einhaltung des
ACID-Prinzips ist genau dann erforderlich, wenn der eine Transaktion ausl¨
osende Anwendungsbaustein nicht Master-Anwendungsbaustein f¨
ur die betroffenen Objekttypen ist, oder nicht
der einzige an der Transaktion beteiligte Master-Anwendungsbaustein f¨
ur die betroffenen Objekttypen ist. Die Einhaltung ist zwischen dem ausl¨
osenden Anwendungsbaustein und allen
(anderen) beteiligten Master-Anwendungsbausteinen erforderlich. Folglich ist eine sorgf¨
altige
Auswahl der Master-Anwendungsbausteine notwendig.
Eine verteilte Transaktion kann so definiert sein, dass in allen beteiligten Anwendungsbausteinen die gleichen Aktionen auszuf¨
uhren sind, oder dass in den beteiligten Anwendungsbausteinen unterschiedliche Aktionen auszuf¨
uhren sind, die jedoch zur selben Transaktion
geh¨
oren. Erstere werden hier als Abgleichstransaktionen bezeichnet, letztere als Kooperationstransaktionen.
Transaktionen und das 3LGM2
Das 3LGM2 und seine Erweiterung zum 3LGM2A wurden als Metamodelle f¨
ur die Unterst¨
utzung
des Informationsmanagements entwickelt, nicht f¨
ur die ausf¨
uhrliche Softwarespezifikation oder
den Datenbankentwurf. Trotzdem kann auch f¨
ur das 3LGM2A ein Bezug zum Transaktionsbegriff
hergestellt werden.
Ein bearbeitender Zugriff einer Aufgabe auf einen Objekttyp kann einen Datenabgleich
zwischen Anwendungsbausteinen bzw. ihren Datenbanksystemen notwendig machen. Jeder
Anwendungsbaustein, der eine Aufgabe unterst¨
utzt, die den zuvor bearbeiteten Objekttyp
interpretiert oder bearbeitet, muss Zugriff auf die aktualisierten Daten, die den betreffenden
Objekttyp repr¨
asentieren, haben. Der Zugriff kann entweder auf das eigene Datenbanksystem erfolgen, oder als Anfrage u
¨ ber Kommunikationsverbindungen auf die Datenbanksysteme
anderer Anwendungsbausteine. Diese Datenbanksysteme m¨
ussen bei der Bearbeitung des be-
158
10.2 Informationale und funktionale Abh¨
angigkeit
treffenden Objekttyps aktualisiert werden, d. h. es m¨
ussen Kommunikationsverbindungen f¨
ur
ihren Abgleich existieren. Diese Aktualisierung kann als Transaktion aufgefasst werden.
10.2 Informationale und funktionale Abh¨
angigkeit
10.2.1 Der informationale Abh¨
angigkeitsgrad
Zwischen Anwendungsbausteinen, an die bestimmte Integrationsanforderungen gestellt werden, bestehen Abh¨
angigkeiten. In vielen F¨allen m¨
ussen anwendungsbezogene Daten zwischen
den Anwendungsbausteinen ausgetauscht werden k¨
onnen. Das wird hier als informationale
Abh¨
angigkeit der Anwendungsbausteine bezeichnet.
Hinweis: Da in abh¨
angigen Anwendungsbausteinen dieselben Informationen (Objekttypen)
u. U. durch unterschiedliche Daten (Datensatztypen und Dokumententypen) repr¨
asentiert
werden, die bei der Kommunikation u
ussen, wird hier, mit Bezug auf die
¨ bersetzt werden m¨
Informationen, die Bezeichnung informationale Abh¨
angigkeit verwendet und nicht eine Bezeichnung wie Datenabh¨
angigkeit.
Zur formalen Beschreibung der informationalen Abh¨
angigkeit wird hier zun¨
achst ein Pr¨
adikat eingef¨
uhrt. Das Pr¨
adikat informational_abhaengig(awb1 , awb2 , objt) gibt an, ob der Anuglich des Objekttyps objt informational abh¨
angig vom Anwenwendungsbaustein awb1 bez¨
dungsbaustein awb2 ist. Anders ausgedr¨
uckt: es gibt an, ob Daten, die den Objekttyp objt
repr¨
asentieren, vom Anwendungsbaustein awb2 zum Anwendungsbaustein awb1 kommuniziert
werden m¨
ussen.
informational_abhaengig(awb1 , awb2 , objt) := awb1 ist bez¨
uglich objt informational abh¨
angig von awb2
(10.1)
Der Wahrheitswert des Pr¨
adikats informational_abhaengig h¨
angt davon ab,
a) ob awb1 und awb2 zur Datendom¨
ane von objt geh¨
oren und
b) ob awb2 Master-Anwendungsbaustein f¨
ur objt ist.
Die Definition f¨
ur informational_abhaengig kann also folgendermaßen pr¨
azisiert werden:
informational_abhaengig(awb1 , awb2 , objt) := awb1 , awb2 ∈ DDomobjt ∧ hat_als_Master(objt, awb2 )
(10.2)
Mit Hilfe des definierten Pr¨
adikates kann der informationale Abh¨
angigkeitsgrad AGI(awb)
eines Anwendungsbausteines awb bestimmt werden. Er wird u
ber
die
Anzahl derjenigen An¨
wendungsbausteine bestimmt, zu denen eine informationale Abh¨
angigkeit besteht. Dabei werden die Anwendungsbausteine mehrfach gez¨
ahlt, zu denen mehrfache Abh¨
angigkeiten bestehen:
AGI(awb) := |{awbi , objtj }| | informational_abhaengig(awb, awbi , objtj )
(10.3)
10.2.2 Der funktionale Abh¨
angigkeitsgrad
Bei funktionaler Integration ben¨
otigt ein Anwendungsbaustein Funktionalit¨
at, die ein anderer
¨
bereitstellt. Das wird hier als funktionale Abh¨
angigkeit bezeichnet. Nach der Uberarbeitung
des
2
at u
3LGM in Abschnitt 7.2.2 kann das Bereitstellen von Funktionalit¨
¨ ber die Klasse Operation
159
10 Abh¨
angigkeit von Anwendungsbausteinen
und ihre Assoziationsbeziehung zur Klasse Aufgabe modelliert werden.
Auch zur formalen Beschreibung der funktionalen Abh¨
angigkeit wird hier zun¨
achst ein Pr¨
adikat eingef¨
uhrt. Das Pr¨
adikat funkional_abhaengig(awb1 , awb2 , auf ) gibt an, ob der Anwendungsbaustein awb1 bez¨
uglich der Aufgabe auf funkional abh¨
angig vom Anwendungsbaustein awb2 ist. Anders ausgedr¨
uckt: es gibt an, ob Operationen, die zur Erf¨
ullung von Aufgabe auf dienen, von Anwendungsbaustein awb1 bei Anwendungsbaustein awb2 aufgerufen
werden.
funktional_abhaengig(awb1 , awb2 , auf ) := awb1 ist bez¨
uglich auf funktional abh¨
angig von awb2
(10.4)
Der Wahrheitswert des Pr¨
adikats funktional_abhaengig h¨
angt davon ab,
a) ob awb1 und awb2 zur funktionalen Dom¨
ane von auf geh¨
oren und
b) ob awb2 Master-Anwendungsbaustein f¨
ur auf ist.
Die Definition f¨
ur funktional_abhaengig kann also folgendermaßen pr¨
azisiert werden:
funktional_abhaengig(awb1 , awb2 , auf ) := awb1 , awb2 ∈ F Domauf ∧ hat_als_Master(auf, awb2 )
(10.5)
Mit Hilfe des definierten Pr¨
adikates kann der funktionale Abh¨
angigkeitsgrad AGF (awb)
eines Anwendungsbausteines awb bestimmt werden. Er wird u
¨ ber die Anzahl derjenigen Anwendungsbausteine bestimmt, zu denen eine funktionale Abh¨
angigkeit besteht. Dabei werden
die Anwendungsbausteine mehrfach gez¨
ahlt, zu denen mehrfache Abh¨
angigkeiten bestehen:
AGF (awb) := |{awbi , aufj }| | funktional_abhaengig(awb, awbi , aufj )
(10.6)
10.3 Ausf¨
uhrungsabh¨
angigkeit, transaktionale Abh¨
angigkeit und
Transaktionsst¨
arke
10.3.1 Die Ausf¨
uhrungsabh¨
angigkeit
Eine zun¨
achst sehr einfach zu beschreibende Abh¨
angigkeit zwischen Anwendungsbausteinen
ist die Ausf¨
uhrungsabh¨
angigkeit. Sie beschreibt die Tatsache, dass Anwendungsbausteine bei
ihrer Ausf¨
uhrung durch andere Anwendungsbausteine blockiert werden k¨
onnen.
¨
Auf der Basis der in Abschnitt 7.2.2 beschriebenen Uberarbeitung des 3LGM2 kann die
Ausf¨
uhrungsabh¨
angigkeit von Anwendungsbausteinen unter Nutzung des Attributs Synchronit¨
atsmodus der Klasse Operation bestimmt werden. Zur Formalisierung wird hier der Ausf¨
uhrungsabh¨
angigkeitsgrad eingef¨
uhrt.
Definition und Berechnungsvorschrift
Definition 10.1 Der Ausfu
angigkeitsgrad AAG gibt f¨
ur einen Anwendungs¨ hrungsabh¨
baustein awb an, von wie vielen anderen Anwendungsbausteinen er bei der Ausf¨
uhrung blockiert werden kann.
Zur Berechnung des Ausf¨
uhrungsabh¨
angigkeitsgrades werden die Operationen gez¨
ahlt, die der
Anwendungsbaustein awb aufruft und deren Attribut Synchronit¨
atsmodus den Wert synchron
160
10.3 Ausf¨
uhrungsabh¨
angigkeit, transaktionale Abh¨
angigkeit und Transaktionsst¨
arke
hat:
AAG(awb∈ AWB)
:=
besitzt(awb, bssi )
∧
|{bssi ∈ BSS}| bssj ∈ BSS ruft_auf(bssi , bssj , op)
∧
∃ op∈ OPER Synchronitaetsmodus(op) = synchron
(10.7)
Ende — Definition und Berechnungsvorschrift
Das in der Berechnungsvorschrift benutzte Pr¨
adikat ruft_auf gibt f¨
ur zwei Bausteinschnittstellen bssi und bssj sowie eine Operation op an, ob eine Kommunikationsbeziehung existiert, bei der bssi aufrufende Bausteinschnittstelle ist, bssj aufgerufene Bausteinschnittstelle ist und op die aufgerufene Operation ist. Auf eine formale Definition des Pr¨
adikates
wird hier verzichtet.
Die in der Berechnungsvorschrift benutzte Funktion Synchronit¨
atsmodus gibt f¨
ur eine Operation op den Wert des Attributes Synchronit¨
atsmodus an. Auch daf¨
ur wird hier auf eine
formale Definition verzichtet.
10.3.2 Die transaktionale Abh¨
angigkeit
Eine weitere Abh¨
angigkeit zwischen Anwendungsbausteinen ist die transaktionale Abh¨
angigkeit. Sie beschreibt die Tatsache, dass Anwendungsbausteine eine Transaktion u. U. zur¨
ucknehmen m¨
ussen, wenn andere an der betreffenden Transaktion beteiligte Anwendungsbausteine
die Durchf¨
uhrung nicht mit einem Commit best¨
atigen.
¨
Auf der Basis der in Abschnitt 7.2.2 beschriebenen Uberarbeitung
des 3LGM2 kann die
transaktionale Abh¨
angigkeit von Anwendungsbausteinen unter Nutzung des Attributs Transaktionsmodus der Assoziationsklasse Kommunikationsbeziehung bestimmt werden. Zur Formalisierung wird hier der Transaktionsabh¨
angigkeitsgrad eingef¨
uhrt.
Definition und Berechnungsvorschrift
Definition 10.2 Der Transaktionsabh¨
angigkeitsgrad T AG gibt f¨
ur einen Anwendungsbaustein awb an, wieviele Anwendungsbausteine die R¨
ucknahme einer Transaktion durch
awb verursachen k¨
onnen.
Zur Berechnung des Transaktionsabh¨
angigkeitsgrades werden die Kommunikationsbeziehungen gez¨
ahlt, die der Anwendungsbaustein awb nutzt und deren Attribut Transaktionsmodus
den Wert Commit erf orderlich hat:
besitzt(awb, bssi )
∧
∧ (10.8)
bssj ∈ BSS ruft_auf(bssi , bssj , op)
T AG(awb∈ AWB) := |{bssi ∈ BSS}| ∃
op∈ OPER T ransaktionsmodus(bssi , bssj , op) = Commit
erforderlich
Ende — Definition und Berechnungsvorschrift
Die in der Berechnungsvorschrift benutzte Funktion Transaktionsmodus gibt f¨
ur zwei Bausteinschnittstellen bssi und bssj sowie eine Operation op den Wert des Attributes Transaktionsmodus der Kommunikationsbeziehung an, u
¨ ber die op von bssi bei bssj aufgerufen wird.
Auf eine formale Definition der Funktion wird hier verzichtet.
161
10 Abh¨
angigkeit von Anwendungsbausteinen
10.3.3 Die Transaktionsst¨
arke einer Transaktionsausf¨
uhrung
Sowohl informationale als auch funktionale Abh¨
angigkeit setzen eine besondere Qualit¨
at der
Kommunikation voraus, damit die Integrationsanforderungen tats¨
achlich erf¨
ullt werden k¨
onnen. Um diese Kommunikationsqualit¨
at beschreiben zu k¨
onnen, wird in diesem Abschnitt der
Begriff der Transaktionsst¨
arke eingef¨
uhrt. Die St¨
arke einer Transaktion ist dabei nicht mit der
Definition einer Transaktion festgelegt. Sie beschreibt einen Zustand der Integration, genauer:
Sie beschreibt die G¨
ute der Integration hinsichtlich der Gew¨
ahrleistung von Datenintegrit¨
at.
Aus der Definition einer Transaktion ergeben sich jedoch m¨
oglicherweise Vorgaben f¨
ur die
Transaktionsst¨
arke der Transaktionsausf¨
uhrung.
Definition und Berechnungsvorschrift
Definition 10.3 Die einfache Transaktionsst¨
arke ase gibt an, wie viele der beteiligten
Anwendungsbausteine ihren Teil der Transaktion best¨
atigen m¨
ussen, damit die Transaktion
im ausl¨
osenden Anwendungsbaustein als ausgef¨
uhrt gilt und folglich nicht zur¨
uckgenommen
werden muss.
Die einfache Transaktionsst¨
arke ase einer Transaktionsausf¨
uhrung ta wird folgendermaßen
berechnet:
1. Der Anfangswert der Berechnung ist 1.
2. F¨
ur jeden beteiligten Nicht-Master-Anwendungsbaustein, der seinen Teil der Transaktion NICHT best¨
atigen muss, wird der Wert 1/(1+Anzahl der beteiligten Nicht-MasterAnwendungsbausteine) abgezogen.
3. F¨
ur jeden Master-Anwendungsbaustein f¨
ur einen der betroffenen Objekttypen, der
seinen Teil der Transaktion NICHT best¨
atigen muss, wird der Wert 1 abgezogen.
Ende — Definition und Berechnungsvorschrift
F¨
ur bestimmte Aussagen u
at ist eine Standardisierung der Trans¨ ber die Integrationsqualit¨
aktionsst¨
arke auf einen Wertebereich zwischen −1 und +1 hilfreich.
Definition und Berechnungsvorschrift
Definition 10.4 Die standardisierte Transaktionsst¨
arke ass ist die einfache Transaktionsst¨
arke einer Transaktionsausf¨
uhrung geteilt durch die Anzahl der Master-Anwendungsbausteine
der betroffenen Objekttypen.
Ende — Definition und Berechnungsvorschrift
10.3.4 Kategorien von Transaktionsausf¨
uhrungen
Zur Erleichterung der Beschreibung von Transaktionsausf¨
uhrungen werden hier die folgenden
Kategorien unterschieden:
vollst¨
andige Ausf¨
uhrungen: Transaktionsausf¨
uhrungen mit einer standardisierten Transaktionsst¨
arke gleich 1 werden hier als vollst¨
andig bezeichnet.
162
10.4 Ein Anwendungsszenario aus dem Universit¨
atsklinikum Leipzig
zul¨
assige Ausf¨
uhrungen: Transaktionsausf¨
uhrungen mit einer standardisierten Transaktionsst¨
arke gr¨
oßer 0 werden hier als zul¨
assig bezeichnet.
unzul¨
assige Ausf¨
uhrungen: Transaktionsausf¨
uhrungen mit einer standardisierten Transaktionsst¨
arke kleiner oder gleich 0 werden hier als unzul¨
assig bezeichnet.
Vollst¨
andige Ausf¨
uhrungen sind also Spezialf¨
alle der zul¨
assigen Ausf¨
uhrungen.
10.4 Ein Anwendungsszenario aus dem Universit¨
atsklinikum Leipzig
Die Anwendung der in diesem Kapitel vorgestellten Kennzahlberechnungen wird hier an einem
Beispielszenario aus dem Universit¨
atsklinikum Leipzig (UKL) demonstriert.
10.4.1 Vorstellung des Anwendungsszenarios
Das hier verwendete Anwendungsszenario ist eine Erweiterung des Anwendungsszenarios aus
Kapitel 9. Abbildung 10.2 zeigt einen Auszug aus dem Informationssystem des UKL, modelliert
auf der Basis des 3LGM2 . Wichtige Anwendungsbausteine sind beispielsweise das Patientenverwaltungssystem, das OP-Planungssystem, das OP-Dokumentationssystem, das Radiologieinformationssystem und das Laborinformationssystem. Der zentrale Anwendungsbaustein f¨
ur
die Unterst¨
utzung der Integration ist der Kommunikationsserver (vgl. Beschreibung des Anwendungsszenarios in Abschnitt 9.2).
¨
Es wird angenommen, dass eine grundlegende Uberarbeitung
der Integrationsinfrastruktur
geplant ist. Die Kommunikation zwischen den Anwendungsbausteinen soll zuk¨
unftig dienstorientiert gestaltet werden. Mit der Umgestaltung soll bei der Infrastruktur f¨
ur die Kommunikation von Falldaten begonnen werden. Dabei sollen Falldaten von einem Master-Patient-Index auf
der Basis des Person Identification Service der OMG bereitsgestellt werden (Abbildung 10.3).
Alte Architektur
Bisher wurden Falldaten im Master-Anwendungsbaustein f¨
ur den Objekttyp Fall, dem Patientenverwaltungssystem, erfasst und u
¨ ber den Kommunikationsserver an andere Anwendungs¨
bausteine verteilt. Die Ubermittlung
der Daten erfolgte zum gr¨
oßten Teil asynchron u
¨ ber
Nachrichtendateien und TCP-Sockets. Abbildung 10.4a hebt
¨
– die Kommunikationsverbindungen der Ubermittlungsdom¨
ane des Objekttyps Fall, des
2
Ereignistyps NP11I0 und des Anwendungsbausteines Patientenverwaltungssystem
(Kommunikationsverbindungen 1 bis 5 ohne 3b) und
¨
– die Kommunikationsverbindungen der Ubermittlungsdom¨
anen des Objekttyps Fall, des
3
Ereignistyps A19 sowie der Anwendungsbausteine RIS-Kommunikationsmodul und
KDMS-MCC (Kommunikationsverbindungen 3b und 6)
2
3
Der Ereignistyp NP11I0 ist im Kommunikationsstandard SAP-HCM definiert und wird im Zusammenhang
mit station¨
aren Patientenaufnahmen ausgel¨
ost. Er entpricht dem Ereignistyp A01 des Kommunikationsstandards HL7.
Der Ereignistyp A19 ist im Kommunikationsstandard HL7 definiert und wird im Zusammenhang mit einer
Abfrage von Falldaten ausgel¨
ost.
163
10 Abh¨
angigkeit von Anwendungsbausteinen
hervor. Die Kommunikationsverbindungen 1 bis 5 ohne 3b gehen vom Patientenverwaltungssys¨
tem aus und f¨
uhren zu den Anwendungsbausteinen, die Anderungen
von Daten zum Objekttyp
Fall auch in ihren Datenbanksystemen durchf¨
uhren m¨
ussen. Zur Vereinfachung wird hier angenommen, dass u
¨ ber die Kommunikationsbeziehungen der Kommunikationsverbindungen 1
bis 5 ohne 3b jeweils nur eine Operation aufgerufen wird, die die zu u
¨ bermittelnden Falldaten
als Parameter entgegennimmt. Die Kommunikationsverbindungen 3b und 6 u
¨ bermitteln Anfragedatens¨
atze an die Anwendungsbausteine RIS-Kommunikationsmodul und KDMS-MCC
als Parameter der aufgerufenen Operationen und Anfrageergebnisse als Ergebnisse der aufgerufenen Operationen.
In der alten Architektur besteht eine große Unabh¨
angigkeit der betrachteten Anwendungsbausteine hinsichtlich der Kommunikation von Falldaten: Bei den Kommunikationsverbindungen 1 bis 5 (ohne 3b) hat das Attribut Synchronit¨
atsmodus aller aufgerufenen Operationen
jeweils den Wert asynchron und das Attribut Transaktionsmodus jeweils den Wert Commit
nicht erforderlich. Bei den Kommunikationsverbindungen 3b und 6 hat das Attribut Synchronit¨
atsmodus der aufgerufenen Operationen jeweils den Wert synchron und das Attribut
Transaktionsmodus jeweils den Wert Commit nicht erforderlich (Abbildung 10.4a).
Der Startpunkt (7) und die Endpunkte (1-6) der elektronischen Kommunikationsverbindungen f¨
ur
Falldaten sind nummeriert.
Abbildung 10.2: Alte Architektur im Anwendungsszenario aus dem UKL; hervorgehoben sind die Anwendungsbausteine
der Datendom¨
ane des Objekttyps Fall, des Ereignistyps NP11I0 und des Anwendungsbausteines Patientenverwaltungssystem
164
10.4 Ein Anwendungsszenario aus dem Universit¨
atsklinikum Leipzig
Die Startpunkte der elektronischen Kommunikationsverbindungen zum PIDS-Modul sind nummeriert.
Abbildung 10.3: Geplante Architektur im Anwendungsszenario aus dem UKL; hervorgehoben sind die Anwendungsbausteine der Datendom¨
ane des Objekttyps Fall, des Ereignistyps NP11I0 und Anwendungsbausteines Patientenverwaltungssystem
Geplante Architektur
Zuk¨
unftig sollen Falldaten von einem zentralen Falldatenverzeichnis, einem Master-PatientIndex (MPI), abgerufen werden. Der MPI sei hier eine Implementierung des Person Identification Service (PIDS) der Object Management Group (OMG) (vgl. Abschnitt 4.2.3). Anwendungsbausteine, die die beiden Ojekttypen interpretieren, sollen die aktuellen Daten zu
einem Fall immer dann vom PIDS abrufen, wenn sie ben¨
otigt werden. Es soll weiterhin m¨
oglich
sein, Falldaten im Patientenverwaltungssystem zu erfassen. Abbildung 10.4b zeigt einen Entwurf f¨
ur die neue Integrationssinfrastruktur, zun¨
achst f¨
ur die Falldaten. Er enth¨
alt u. a. einen
Anwendungsbaustein, der den PIDS zur Verf¨
ugung stellt, und einen Object Request Broker
(ORB) als zentralen Anwendungsbaustein f¨
ur die Integration. In der Abbildung sind
¨
– die Kommunikationsverbindung der Ubermittlungsdom¨
ane des Objekttyps Fall, des Ereignistyps NP11I0 und des Anwendungsbausteins Patientenverwaltungssystem (Kommunikationsverbindung 7) und
¨
– die Kommunikationsverbindungen der Ubermittlungsdom¨
ane des Objekttyps Fall, des
Ereignistyps A19 und des Anwendungsbausteines PIDS (Kommunikationsverbindungen 1 bis 6)
hervorgehoben. Zu letztgenannten Anwendungsbausteinen geh¨
oren u. a. das Laborinformationssystem und Radiologieinformationssystem.
165
10 Abh¨
angigkeit von Anwendungsbausteinen
a)
b)
Bei a) sind die Endpunkte der Kommunikationsverbindungen vom Patientenverwaltungssystem zu
den Ziel“-Anwendungsbausteinen der Falldaten nummeriert. Bei b) sind die Startpunkte der Kom”
munikationsverbindungen zum PIDS-Modul nummeriert. Die Kommunikationsbeziehungen sind mit
Abk¨
urzungen f¨
ur das Attribut Transaktionsmodus und f¨
ur das Attribut Synchronit¨
atsmodus versehen: synchron, asynchron, Commit erforderlich, Commit nicht erforderlich
Abbildung 10.4: Anwendungsszenario aus dem UKL mit Kommunikationsserver (a) und mit ORB (b); hervorgehoben
sind die Kommunikationsverbindungen zur Verteilung der Falldaten
166
10.4 Ein Anwendungsszenario aus dem Universit¨
atsklinikum Leipzig
Die Kommunikationsverbindung 7 geht vom Patientenverwaltungssystem aus und f¨
uhrt zum
¨
PIDS-Modul, der die Anderungen
von Daten zum Objekttyp Fall auch in seinem Datenbanksystem durchf¨
uhren muss. Zur Vereinfachung wird hier angenommen, dass u
¨ ber die Kommunikationsverbindung 7 nur die Operation find or register ids des PIDS aufgerufen wird
(vgl. [OMG 2001c], S. 2-28 - 2-32). Die Kommunikationsverbindungen 1 bis 6 u
¨ bermitteln
Anfragen an den Anwendungsbaustein PIDS-Modul als Parameter der aufgerufenen Operationen und Anfrageergebnisse als Ergebnisse der aufgerufenen Operationen. Zur Vereinfachung wird hier angenommen, dass u
¨ ber die Kommunikationsverbindungen 1 bis 6 nur die
Operation find candidates des PIDS aufgerufen wird (vgl. [OMG 2001c], S. 2-19 - 2-21).
Ebenfalls zur Vereinfachung wurden, im Gegensatz zum Beispiel in Abschnitt 7.6.2, am ORB
die Schnittstellen-Elemente f¨
ur die IDL-Stubs und die Skeletons zusammengefasst.
¨
¨
Uber die f¨
ur die geplante Architektur betrachteten vereinigten Ubermittlungsdom¨
anen soll
dieselbe Funktionalit¨
at bereit gestellt werden wie u
ur die alte Architektur betrachtete
¨ ber die f¨
¨
Ubermittlungsdom¨
ane: die Verteilung der Falldaten4 .
In der geplanten Architektur sind sowohl das Patientenverwaltungssystem als auch der PIDSModul Master-Anwendungsbaustein f¨
ur den Objekttyp Fall. Um die Bestimmung nicht zul¨
assiger Transaktionen zu demonstrieren, wurde die in der Praxis notwendige Kommunikati¨
onsverbindung zur Ubermittlung
von aktualisierten Falldaten vom PIDS-Modul zum Patientenverwaltungssystem weggelassen.
In der geplanten Architektur besteht eine wesentlich geringere Unabh¨
angigkeit der betrachteten Anwendungsbausteine hinsichtlich der Kommunikation von Falldaten: Bei den Kommunikationsverbindungen 1 bis 6 hat das Attribut Synchronit¨
atsmodus aller aufgerufenen Operationen jeweils den Wert synchron und das Attribut Transaktionsmodus jeweils den Wert
Commit nicht erforderlich. Bei der Kommunikationsverbindungen 7 hat das Attribut Synchronit¨
atsmodus der aufgerufenen Operationen jeweils den Wert synchron und das Attribut
Transaktionsmodus jeweils den Wert Commit erforderlich (Abbildung 10.4b).
10.4.2 Kennzahlen zur Abh¨
angigkeit f¨
ur das Anwendungsszenario
Im Folgenden werden nur die Anwendungsbausteine ber¨
ucksichtigt, die zu den bei der Vor¨
stellung des Anwendungsszenarios in Abschnitt 10.4 beschriebenen Ubermittlungsdom¨
anen
geh¨
oren.
F¨
ur die vorgestellte alte Architektur haben die in diesem Kapitel vorgestellten Kennzahlen
folgende Werte:
1. AGI(P atientenverwaltungssystem) = 0.
2. AGI(awbi ) = 1 f¨
ur
–
–
–
–
–
–
4
das
das
das
das
das
das
COPRA-basierte Patientendatenmanagementsystem,
Laborinformationssystem,
Radiologieinformationssystem RAD,
Pathologieinformationssystem,
MCC-basierte Klinische Dokumentations- und Managementsystem und
Endoskopie-/Sonographiedokumentationssystem.
Ereignistypen zu Verlegungen, Entlassungen, Patientenzusammenf¨
uhrungen oder weiteren fallbezogenen Ereignissen werden hier zur Vereinfachung nicht ber¨
ucksichtigt.
167
10 Abh¨
angigkeit von Anwendungsbausteinen
Diese Anwendungsbausteine sind vom Patientenverwaltungssystem informational abh¨
angig.
ur
3. AGF (awbi ) = 0 f¨
–
–
–
–
das
das
das
das
COPRA-basierte Patientendatenmanagementsystem,
Laborinformationssystem,
Pathologieinformationssystem und
MCC-basierte Klinische Dokumentations- und Managementsystem.
4. AGF (awbi ) = 1 f¨
ur
– das Radiologieinformationssystem RAD und
– das Endoskopie-/Sonographiedokumentationssystem.
Das Radiologieinformationssystem ist vom RIS-Kommunikationsmodul funktional abh¨
angig, das Endoskopie-/Sonographiedokumentationssystem vom MCC-basierten Klinischen Dokumentations- und Managementsystem. Die funktionale Abh¨
angigkeit ist auf
die Aufgabe Suche von Falldaten bezogen.
5. AAG(awbi ) = 0 f¨
ur
–
–
–
–
das
das
das
das
COPRA-basierte Patientendatenmanagementsystem,
Laborinformationssystem,
Pathologieinformationssystem und
MCC-basierte Klinische Dokumentations- und Managementsystem.
6. AAG(awbi ) = 1 f¨
ur
– das Radiologieinformationssystem RAD und
– das Endoskopie-/Sonographiedokumentationssystem.
Das Radiologieinformationssystem h¨
angt bei der Ausf¨
uhrung vom RIS-Kommunikationsmodul
ab, das Endoskopie-/Sonographiedokumentationssystem vom MCC-basierten Klinischen
Dokumentations- und Managementsystem.
7. T AG(awbi ) = 0 f¨
ur alle Anwendungsbausteine.
1
8. ase = /6 f¨
ur die Transaktion, die durch den bearbeitenden Zugriff auf den Objekttyp
Fall im Patientenverwaltungssystem ausgel¨
ost wird.
1
9. ass = /6 f¨
ur die beschriebene Transaktion; die Transaktion ist folglich zul¨
assig.
F¨
ur die vorgestellte geplante Architektur haben die in diesem Kapitel vorgestellten Kennzahlen
folgende Werte:
1. AGI(awbi ) = 0 f¨
ur
– das Patientenverwaltungssystem und
– den PIDS-Modul.
2. AGI(awbi ) = 2 f¨
ur
–
–
–
–
–
–
das
das
das
das
das
das
COPRA-basierte Patientendatenmanagementsystem,
Laborinformationssystem,
Radiologieinformationssystem RAD,
Pathologieinformationssystem,
MCC-basierte Klinische Dokumentations- und Managementsystem und
Endoskopie-/Sonographiedokumentationssystem.
Diese Anwendungsbausteine sind vom Patientenverwaltungssystem und vom PIDS-
168
10.4 Ein Anwendungsszenario aus dem Universit¨
atsklinikum Leipzig
Modul informational abh¨
angig.
3. AGF (awb1 ) = 1 f¨
ur
–
–
–
–
–
–
das
das
das
das
das
das
COPRA-basierte Patientendatenmanagementsystem,
Laborinformationssystem,
Radiologieinformationssystem RAD,
Pathologieinformationssystem,
MCC-basierte Klinische Dokumentations- und Managementsystem und
Endoskopie-/Sonographiedokumentationssystem.
Diese Anwendungsbausteine sind vom PIDS-Modul funktional abh¨
angig. Die funktionale Abh¨
angigkeit ist auf die Aufgabe Suche von Falldaten bezogen.
4. AAG(awbi ) = 0 f¨
ur
– den PIDS-Modul.
ur
5. AAG(awbi ) = 1 f¨
–
–
–
–
–
–
–
das
das
das
das
das
das
das
Patientenverwaltungssystem,
COPRA-basierte Patientendatenmanagementsystem,
Laborinformationssystem,
Radiologieinformationssystem RAD,
Pathologieinformationssystem,
MCC-basierte Klinische Dokumentations- und Managementsystem und
Endoskopie-/Sonographiedokumentationssystem.
Diese Anwendungsbausteine h¨
angen bei der Ausf¨
uhrung vom PIDS-Modul ab.
6. T AG(awbi ) = 0 f¨
ur
–
–
–
–
–
–
–
den PIDS-Modul,
das COPRA-basierte Patientendatenmanagementsystem,
das Laborinformationssystem,
das Radiologieinformationssystem RAD,
das Pathologieinformationssystem,
das MCC-basierte Klinische Dokumentations- und Managementsystem und
das Endoskopie-/Sonographiedokumentationssystem.
7. T AG(awbi ) = 1 f¨
ur das Patientenverwaltungssystem.
8. ase = 1 f¨
ur die Transaktion, die durch den bearbeitenden Zugriff auf den Objekttyp
Fall im Patientenverwaltungssystem ausgel¨
ost wird.
9. ass = 1 f¨
ur die beschriebene Transaktion; die Transaktion ist folglich zul¨
assig.
10. ase = 0 f¨
ur die Transaktion, die durch den bearbeitenden Zugriff auf den Objekttyp
Fall im PIDS-Modul ausgel¨
ost wird.
11. ass = 0 f¨
ur die beschriebene Transaktion; die Transaktion ist folglich unzul¨
assig.
In der geplanten Architektur besteht eine h¨
ohere Abh¨
angigkeit der Anwendungbausteine. Sie
¨
muss außerdem um eine Kommunikationsverbindung zur Ubermittlung
von aktualisierten Falldaten vom PIDS-Modul zum Patientenverwaltungssystem erg¨
anzt werden.
169
11 Heterogenit¨
atsbewertung von Kommunikationsverbindungen
11.1 Vorbemerkungen
In vielen Informationssystemen werden viele unterschiedliche Integrationstechniken verwendet. Diese Heterogenit¨
at wird oft dadurch gef¨
ordert, dass die Auswirkungen der Einf¨
uhrung
einer neuen Integrationstechnik und das Einsparungspotential bei der Nutzung vorhandener
Integrationstechniken nicht analysiert wird.
Die in diesem Kapitel erarbeiteten Kennzahlen unterst¨
utzen die Analyse der Heterogenit¨
at,
bis hin zu einem Versuch der Absch¨
atzung von Einsparungspotential bei Integrationskosten.
11.2 Der absolute Heterogenit¨
atsgrad von Kommunikationsverbindungen
11.2.1 Der absolute Heterogenit¨
atsgrad von zwei Kommunikationsverbindungen
Der absolute Heterogenit¨
atsgrad H erlaubt eine quantitative Einsch¨
atzung der Wiederverwendung von Integrationstechniken. Er gibt an, wie stark sich Kommunikationsverbindungen
hinsichtlich der beteiligten Kommunikationsbeziehungen und der zugeh¨
origen Vermittlungsbeziehungen unterscheiden.
F¨
ur die Bestimmung des Heterogenit¨
atsgrades werden Kommunikationsverbindungen hinsichtlich der zugeh¨
origen Bausteinschnittstellen und der aufgerufenen Operationen miteinander verglichen. Im Abschnitt 8.6.1 wurden dazu Kommunikationsverbindungen als Folgen
von Kommunikationsbeziehungen formalisiert.
Zur Bestimmung des absoluten Heterogenit¨
atsgrades H wird zun¨
achst ein Gleichheitswert
(similarity score) p bestimmt. Der Gleichheitswert von zwei Kommunikationsverbindungen wird
a
¨hnlich dem Gleichheitswert von zwei Nukleotidsequenzen bei der Genomanalyse [Pearson
2001] bestimmt. Dort wird beim Ausrichten der Sequenzen aneinander f¨
ur jede Abweichung
¨
eine Strafe“ vergeben, f¨
ur jede Ubereinstimmung
eine Gutschrift“. Beim Ausrichten werden
”
”
die Symbolsequenzen so gegen¨
ubergestellt, dass die Summe der Strafen“ und Gutschriften“
”
”
maximal wird. Dabei werden Strafen“ i. d. R. mit einem negativen Wert versehen.
”
Hier wird der Needleman-Wunsch-Algorithmus (NW-Algorithmus) zur globalen Ausrichtung von Symbolsequenzen angewendet (Kasten Exkurs: Ausrichtung von Symbolsequenzen“;
”
[Pearson 2001], S. 22-27, [Needleman and Wunsch 1970]). Der Algorithmus liefert f¨
ur zwei
Sequenzen eine Ausrichtung mit der geringsten Abweichung.
F¨
ur die Berechnung der Gleichheit von zwei Kommunikationsverbindungen werden die Sequenzen der Tupel der Kommunikationsbeziehungen aneinander ausgerichtet. Dabei werden
¨
die Abweichungen und Ubereinstimmungen
nach der folgenden Vorschrift bewertet. Die Abbildungen 11.1 und 11.2 k¨
onnen das Verstehen der Vorschrift unterst¨
utzen.
171
11 Heterogenit¨
atsbewertung von Kommunikationsverbindungen
Kasten 11.1: Exkurs: Ausrichtung von Symbolsequenzen
Needleman-Wunsch-Algorithmus
Der Algorithmus von Needleman und Wunsch ([Pearson 2001], S. 22-27, [Needleman and Wunsch 1970]) ist prinzipiell nicht auf die Ausrichtung von Nukleotidsequenzen beschr¨
ankt. Er berechnet rekursiv die besten Ausrichtungen
f¨
ur zwei Symbolsequenzen. In einer Matrix der zwei Sequenzen bestimmt er, oben links beginnend, f¨
ur jedes Feld der
Matrix einen Gleichheitswert (similarity score). Die Berechnungsvorschrift f¨
ur den Gleichheitswert pi,j f¨
ur das Feld
an Position (i, j) ist:
pi,j | i = 0 ∨ j = 0
:=
pi,j | i, j > 0
:=
¨
Dabei ist s((k, l), (i, j)) der Wert f¨
ur den Ubergang
¨
vom Feld (k, l) zum benachbarten Feld (i, j). Ubli¨
cherweise wird ein diagonaler Ubergang
von einem
Feld (i − 1, j − 1) zum Feld (i, j) mit einem positiven Wert bewertet ( Gutschrift“), wenn die zugeh¨
ori”
gen Symbole der beiden Sequenzen gleich sind. Jeder
¨
waagerechte oder senkrechte Ubergang
wird mit einem negativen Wert ( Strafe“) bewertet. Waagerechte
”
¨
¨
und senkrechte Uberg¨
ange, d. h. Uberg¨
ange, bei denen sich nur einer der beiden Indizes ¨
andert, f¨
uhren
zum Einf¨
ugen einer L¨
ucke (engl: gap) in derjenigen
Sequenz, deren Index sich nicht ¨
andert.
ur
In der Beispielmatrix betr¨
agt die Gutschrift“ f¨
”
¨
einen diagonalen Ubergang
mit gleichen Symbolen
¨
1. Die Strafe“ f¨
ur einen diagonalen Ubergang
mit
”
ungleichen Symbolen betr¨
agt −1, f¨
ur jeden anderen
¨
Ubergang
-2.
Um die besten Ausrichtungen herauszufinden, werden, ausgehend von der unteren rechten Ecke der Matrix, die Pfade mit den gr¨
oßten Gleichheitswerten gesucht.
0
8
9
, (i, j))=
<pi−1,j +s((i − 1, j)
max pi−1,j−1 +s((i − 1, j − 1), (i, j))
:
;
pi,j−1 +s((i, j − 1)
, (i, j))
A
B
D
E
G
K
H
I
A
\
1
\ !
-1
\
-1
\
-1
\
-1
\
-1
\
-1
\
-1
B
\
_-1
\
2
!
0
\ !
-2
\
-2
\
-2
\
-2
\
-2
D
\
D
\
-1
_ 0
\
3
!
1
!
-1
\ !
-3
\
-3
\
-3
-1
\
_-2
\
_ 1
\
2
\ !
0
\ !
-2
\ !
-4
\
-4
E
\
F
\
-1
\
G
\
-1
\
H
\
-1
\
-2 -2
\
\
_-1 _-3 -3
\
2 _ 0 _-2
\
\
\
1
1
1
\ ! \
\
-1
0
0
\ ! \ ! \
-3 -2 -1
\ ! \ ! \ !
-5 -4 -3
I
\
-1
\
-2
-1
\
-2
\
-2
\
-3 -3
\
\
_-4 -4
_-1
\
0
\
1
!
-1
_-3
\
_-2
\
_-1
\
2
Optimal global alignments (score 2):
or
A B D D E F G H I
A B D - E G K H I
A B - D E G K H I
(top)
(side)
(Bildquelle: [Pearson 2001], S. 25)
Definition und Berechnungsvorschrift
Definition 11.1 Der absolute Gleichheitswert p von zwei Kommunikationsverbindungen
ist ein Maß f¨
ur die Abweichung der Kommunikationsverbindungen hinsichtlich der zugeh¨
origen
Bausteinschnittstellen und der aufgerufenen Operationen.
1. F¨
ur die Berechnung von p werden die Kommunikationsverbindungen aneinander ausgerichtet. Die Ausrichtung der Kommunikationsverbindungen erfolgt dazu nach einer
Anpassung des Needleman-Wunsch-Algorithmus (NW-Algorithmus) zur globalen Ausrichtung von Symbolsequenzen.
2. F¨
ur die Berechnung des Gleichheitswertes (similarity score) werden die betrachteten
Kommunikationsverbindungen in einer Matrix gegen¨
ubergestellt. Der Gleichheitswert
wird dar¨
uber bestimmt, dass der Weg durch die Matrix gesucht wird, der den h¨
ochsten
Gleichheitswert in der letzten (meist unteren rechten) Zelle ergibt.
3. Die Anpassung des NW-Algorithmus erfolgt durch folgende Regeln:
172
11.2 Der absolute Heterogenit¨
atsgrad von Kommunikationsverbindungen
3.1. Die Kommunikationsbeziehungen werden entsprechend der Definitionsgleichung
8.49 in Abschnitt 8.6.2 als Tripelfolgen notiert1 .
3.2. Die Kommunikationsverbindungen werden zur Vorbereitung der Anwendung des
NW-Algorithmus in Matrixform notiert. Jedes Tripel bildet ein Symbol im Sinne
des NW-Algorithmus.
3.3. Der Gleichheitswert di,j von zwei einzelnen Kommunikationsbeziehungen wird
nach folgenden Regeln bestimmt:
3.3.1. Der Startwert f¨
ur die Berechnung ist 0.
3.3.2. Es werden jeweils die aufgerufenen Bausteinschnittstellen miteinander
und die Operationen miteinander verglichen.
3.3.3. Ist eine der beiden verglichenen Kommunikationsbeziehungen das erste Element einer der betrachteten Kommunikationsverbindungen, werden auch die
aufrufenden Bausteinschnittstellen miteinander verglichen.
¨
3.3.4. F¨
ur jede Ubereinstimmung
der Bausteinschnittstellen oder der Operationen wird eine Gutschrift“ von 0 addiert.
”
3.3.5. F¨
ur jede Abweichung einer Bausteinschnittstelle oder einer Operation
wird eine Strafe“ von −1 addiert.
”
3.4. Die im NW-Algorithmus verrechneten Werte f¨
ur die Ausgangsfelder und f¨
ur die
¨
Uberg¨
ange zwischen den Matrixfeldern werden nach den folgenden Regeln bestimmt:
3.4.1. F¨
ur jedes Feld mit i = 0 gilt: pi,j := j ∗ (−1).
3.4.2. F¨
ur jedes Feld mit j = 0 gilt: pi,j := i ∗ (−1).
¨
3.4.3. F¨
ur jeden diagonalen Ubergang
(i−1, j−1) → (i, j) zu einem Feld mit gleichen
Kommunikationsbeziehungen wird eine Gutschrift“ s((i − 1, j − 1), (i, j)) in
”
H¨
ohe des Gleichheitswertes di,j = 0 der beiden Kommunikationsbeziehungen
vergeben (vgl. Regel 3.3).
¨
3.4.4. F¨
ur jeden diagonalen Ubergang
(i − 1, j − 1) → (i, j) zu einem Feld mit abweichenden Kommunikationsbeziehungen wird eine Strafe“ s((i−1, j −1), (i, j))
”
in H¨
ohe des Gleichheitswertes di,j der beiden Kommunikationsbeziehungen
vergeben (vgl. Regel 3.3).
¨
3.4.5. F¨
ur jeden waagerechten Ubergang
(i, j − 1) → (i, j) mit i + j > 1 und jeden
¨
senkrechten Ubergang (i − 1, j) → (i, j) mit i + j > 1, d. h. beim Einf¨
ugen
einer L¨
ucke, wird eine Strafe“ von −1 vergeben.
” ¨
3.4.6. F¨
ur jeden waagerechten Ubergang
(i, j − 1) → (i, j) mit i = 0 ∧ j = 1 und
¨
jeden senkrechten Ubergang
(i − 1, j) → (i, j) mit i = 1 ∧ j = 0, d. h. beim
Einf¨
ugen der ersten L¨
ucke vor der ersten Kommunikationsbeziehung einer
der betrachteten Kommunikationsverbindungen, wird eine Strafe“ von −2
”
vergeben.
3.5. F¨
ur jedes mehrfache Auftreten eines bestimmten Vergleichspaares von aufgerufenen Bausteinschnittstellen und f¨
ur jedes mehrfache Auftreten eines Vergleichspaares von Operationen wird keine Strafe“ von −1 beim Ausrichten der Kommu”
nikationsverbindungen und Berechnen des absoluten Gleichheitswertes vergeben2 .
1
2
Da die Abweichungen f¨
ur Vermittlungsverbindungen separat berechnet werden, gen¨
ugt zun¨
achst die Tripelnotation. Um die Vermittlungsverbindungen nicht zu vergessen, kann die Verwendung der Quadrupelnotation
sinnvoll sein.
Durch diese und die folgende Regel werden Abweichungen bestimmter Bausteinschnittstellen bzw. Operationen nur einmal und nicht mehrfach gez¨
ahlt (siehe die Erl¨
auterungen zu diesen Regeln am Ende dieses
173
11 Heterogenit¨
atsbewertung von Kommunikationsverbindungen
Auszurichtende Kommunikationsverbindungen:
(bss1 , bss2 , op1 , hi), (bss2 , bss3 , op3 , hi), (bss3 , bss4 , op4 , hi), (bss4 , bss5 , op5 , hi)
(bss1 , bss2 , op2 , hi), (bss2 , bss3 , op3 , hi), (bss3 , bss6 , op6 , hi), (bss6 , bss4 , op7 , hi), (bss4 , bss5 , op5 , hi)
Anwendung des Needleman-Wunsch-Algorithmus:
j=0
j=1
j=2
j=3
j=4
i=0
(bss1 , bss2 , op1 ) (bss2 , bss3 , op3 ) (bss3 , bss4 , op4 ) (bss4 , bss5 , op5 )
i = 1 (bss1 , bss2 , op2 )
−1
−2
−3
−4
i=
i=
i=
i=
2
3
4
5
(bss2 , bss3 , op3 )
(bss3 , bss6 , op6 )
(bss6 , bss4 , op7 )
(bss4 , bss5 , op5 )
−2
−3
−4
−5
−1
−2
−3
−4
d1,1 = −1 = 0 + 0 − 1 = s((0, 0), (1, 1)) ; p1,1 =
-1
d1,2 = −2 = −1 − 1
= s((0, 1), (1, 2)) ; p1,2 =
-2
d1,3 = −2 = −1 − 1
= s((0, 2), (1, 3)) ; p1,3 =
-3
d2,2 =
= s((1, 1), (2, 2)) ; p2,2 =
-1
0 = 0+0
−2
−3
−3
−4
8
< p0,1
p0,0
= max
:
p1,0
8
< p0,2
= max
p0,1
:
p1,1
8
< p0,3
= max
p0,2
:
p1,2
8
< p1,2
= max
p1,1
:
p2,1
−3
−4
−4
−3
+ s((0, 1), (1, 1)) = −1 −1 = −2
+ s((0, 0), (1, 1)) = −0 −1 = −1
+ s((1, 0), (1, 1)) = −1 −1 = −2
+ s((0, 2), (1, 2)) = −2 −1 = −3
+ s((0, 1), (1, 2)) = −1 −2 = −3
+ s((1, 1), (1, 2)) = −1 −1 = −2
+ s((0, 3), (1, 3)) = −3 −1 = −4
+ s((0, 2), (1, 3)) = −3 −2 = −5
+ s((1, 2), (1, 3)) = −2 −1 = −3
+ s((1, 2), (2, 2)) = −2 −1 = −3
+ s((1, 1), (2, 2)) = −1 +0 = −1
+ s((2, 1), (2, 2)) = −2 −1 = −3
Ausgerichtete Kommunikationsverbindungen:
(bss1 , bss2 , op1 , hi),(bss2 , bss3 , op3 , hi),
(bss3 , bss4 , op4 , hi),(bss4 , bss5 , op5 , hi)
+0 + 0 − 1
+0 + 0 + 0
+0 − 1
+1 + 0 − 1
+0 + 0 + 0
(bss1 , bss2 , op2 , hi),(bss2 , bss3 , op3 , hi),(bss3 , bss6 , op6 , hi),(bss6 , bss4 , op7 , hi),(bss4 , bss5 , op5 , hi)
Der Gleichheitswert der beiden Kommunikationsverbindungen ist -3.
Abbildung 11.1: Ausrichtung von zwei Kommunikationsverbindungen
3.6. Existieren beim Ausrichten von Kommunikationsverbindungen Alternativen, d. h.
mehrere m¨
ogliche Wege durch die Matrix, dann werden die Alternativen bevorzugt, bei denen bestimmte Vergleichspaare mehrfach auftreten.
3.7. F¨
ur alle Vermittlungsverbindungen der betrachteten Kommunikationsverbindungen wird, getrennt nach der Vermittlungsstufe, der Gleichheitswert separat bestimmt und zum Gleichheitswert der urspr¨
unglich betrachteten Kommunikations3
verbindungen addiert .
3.8. F¨
ur Vermittlungsverbindungen wird f¨
ur jede der m¨
oglichen Abweichungen die
H¨
alfte des Wertes addiert, der auf der u
bergeordneten
Kommunikationsstufe f¨
ur
¨
eine solche Abweichung addiert w¨
urde.
Ende — Definition und Berechnungsvorschrift
Auf der Basis des absoluten Gleichheitswertes wird der absolute Heterogenit¨
atsgrad definiert:
3
Abschnittes).
Sehr oft werden mehr als zwei Vermittlungsverbindungen ausgerichtet werden m¨
ussen. Eine allgemeine Vorschrift f¨
ur die Ausrichtung beliebig vieler Kommunikationsverbindungen und die Bestimmung des zugeh¨
origen
Gleichheitswertes wird in Abschnitt 11.2.2 angegeben.
174
11.2 Der absolute Heterogenit¨
atsgrad von Kommunikationsverbindungen
Zu vergleichende Kommunikationsverbindungen:
(bss1 , bss2 , op1 ,
h (bss7 , bss8 , op4 ,
)
)i
h(bss11 , bss12 , op7 , hi)i
(bss1 , bss2 , op2 ,
h (bss7 , bss8 , op6 ,
), (bss2 , bss3 , op3 , hi)
)i
h(bss11 , bss12 , op7 , hi)i
Ausrichtung und Vergleich der Kommunikationsbeziehungen:
(bss1 ,bss2 ,op1 ,h. . .i)
0 +0 −1
−1
= −2
(bss1 ,bss2 ,op2 ,h. . .i), (bss2 ,bss3 ,op3 , h. . .i)
Ausrichtung und Vergleich der Vermittlungsbeziehungen (Stufe 1):
(bss7 ,bss8 , op4 , h. . .i)
0 +0 −0, 5
= −0, 5
(bss7 ,bss8 , op6 , h. . .i)
Ausrichtung und Vergleich der Vermittlungsbeziehungen (Stufe 2):
(bss11 ,bss12 ,op7 ,hi)
0
+0 +0
=0
(bss11 ,bss12 ,op7 ,hi)
Der Gleichheitswert:
p(kv1 , kv2 ) = −2 − 0, 5 + 0 = −2, 5
Abbildung 11.2: Berechnung des Gleichheitswertes p von zwei ausgerichteten Kommunikationsverbindungen mit Vermittlungsverbindungen
Definition 11.2 Der absolute Heterogenit¨
atsgrad H von zwei Kommunikationsverbindungen ist gleich dem Betrag ihres absoluten Gleichheitswertes:
H(kv1, kv2) := |p(kv1, kv2)|
H: absoluter Heterogenit¨
atsgrad
p : absoluter Gleichheitswert
(11.1)
Ende — Definition und Berechnungsvorschrift
¨
Die Festlegung der Bewertung von Ubereinstimmungen
und Abweichungen
Der Heterogenit¨
atsgrad soll Abweichungen von Kommunikationsverbindungen angeben. Des¨
halb werden Ubereinstimmungen
hier nur mit dem Wert 0 angerechnet (Regel 3.3.4). Abwei¨
chungen k¨
onnen folglich nicht durch Ubereinstimmungen
aufgehoben“ werden. Damit ist der
”
Gleichheitswert stets kleiner oder gleich 0. Der gr¨
oßtm¨
ogliche Betrag f¨
ur die Abweichung von
zwei Kommunikationsbeziehungen ist 2 = | − 2|: Abweichung der aufgerufenen Bausteinschnittstellen plus Abweichung der Operationen (Regeln 3.3.2 und Regel 3.3.5). Eine Ausnahme bilden die jeweils ersten Kommunikationsbeziehungen der betrachteten Kommunikationsverbindungen. Der gr¨
oßtm¨
ogliche Betrag f¨
ur die Abweichung dieser Kommunikationsbeziehungen ist 3 = | − 3|: Abweichung der aufrufenden Bausteinschnittstellen plus Abweichung
175
11 Heterogenit¨
atsbewertung von Kommunikationsverbindungen
der aufgerufenen Bausteinschnittstellen plus Abweichung der Operationen (Regeln 3.3.3
und 3.3.5).
Die Festlegung des Wertes −1 als Basiswert f¨
ur eine Abweichung einer Bausteinschnittstelle oder einer Operation ist zun¨
achst willk¨
urlich (Regel 3.3.5). Der Basiswert k¨
onnte durch
einen beliebigen anderen (negativen) Wert ersetzt werden. Die Festlegung der u
¨ brigen Werte
f¨
ur Abweichungen muss dann im selben Verh¨
altnis erfolgen. Dann entstehen andere absolute
Betr¨
age f¨
ur die Gleichheitswerte und die Heterogenit¨
atsgrade, aber die Ordnungsrelationen
gr¨
oßer als“ (>) und kleiner als“ (<) bleiben gleich.
”
”
Der Wert −1 f¨
ur das Einf¨
ugen einer L¨
ucke ist gleich der H¨
alfte der gr¨
oßtm¨
oglichen Abweichung von zwei Kommunikationsbeziehungen (Regel 3.4.5). Damit ist es f¨
ur die Berechnung
des Heterogenit¨
atsgrades unerheblich, ob zwei vollst¨
andig unterschiedliche Kommunikationsbeziehungen bei der Ausrichtung u
ugen von L¨
ucken gegen¨ bereinandergelegt oder durch Einf¨
einander verschoben werden:
(. . .)(bss2 , bss3 , op2 )(. . .)
−1 − 1 − 1
(. . .)(bss5 , bss6 , op4 )(. . .)
=
(. . .)(bss2 , bss3 , op2 )
(. . .)
−1
−1
(. . .)
(bss5 , bss6 , op4 )(. . .)
Diese Flexibilit¨
at ist insbesondere beim Ausrichten von mehr als zwei Kommunikationsverbindungen n¨
utzlich (siehe Abschnitt 11.2.2). Dabei k¨
onnen u. U. g¨
unstigere Ausrichtungen entstehen, wenn bestimmte vollst¨
andig abweichende Kommunikationsbeziehungen gegeneinander
verschoben werden. Dabei ¨
andert sich der Gleichheitswert der Kommunikationsverbindungen
mit den gegeneinander verschobenen Kommunikationsbeziehungen nicht.
Durch die zus¨
atzlichen Regeln f¨
ur die Vergleiche der jeweils ersten Kommunikationsbeziehungen der betrachteten Kommunikationsverbindungen wird erreicht, dass auch die aufrufenden Bausteinschnittstellen dieser Kommunikationsbeziehungen in den Vergleich einbezogen werden (Regel 3.3.3). Bei den darauf folgenden Kommunikationsbeziehungen ist die aufrufende Bausteinschnittstelle zugleich die aufgerufene Bausteinschnittstelle der vorhergehenden Kommunikationsbeziehung und sollte folglich nicht doppelt“ verrechnet werden.
”
Deshalb werden, mit Ausnahme der Vergleiche mit Beteiligung einer ersten Kommunikationsbeziehung, immer nur die aufgerufenen Bausteinschnittstellen und die Operationen
miteinander verglichen.
ur die erste L¨
ucke vor der jeweils ersten KommunikationsDurch die besondere Strafe“ f¨
”
beziehung einer Kommunikationsverbindung (Regel 3.4.6) wird auch f¨
ur die ersten Kommunikationsbeziehungen erreicht, dass sie bei vollst¨
andiger Abweichung bei der Ausrichtung
u
ugen von L¨
ucken gegeneinander verschoben werden k¨
on¨ bereinandergelegt oder durch Einf¨
nen:
(bss1 , bss2 , op1 )(. . .)
−1 − 1 − 1
(bss3 , bss4 , op2 )(. . .)
=
(bss1 , bss2 , op1 )
(. . .)
−2
−1
(bss3 , bss4 , op2 )(. . .)
Die Regeln f¨
ur die Ber¨
ucksichtigung von Zyklen in Kommunikationsverbindungen
Die vorgestellte Berechnungsvorschrift f¨
ur den absoluten Gleichheitswert kann zu wenig sinnvollen Ergebnissen f¨
uhren, wenn die Regeln 3.5 und 3.6 weggelassen werden. Problematisch
sind dann solche Szenarios, bei denen innerhalb einer Kommunikationsverbindung bestimmte
176
11.2 Der absolute Heterogenit¨
atsgrad von Kommunikationsverbindungen
(bss1 , bss2 , op1 )(bss2 , bss3 , op2 )(bss3 , bss4 , op3 )(bss4 , bss5 , op4 )
(bss1 , bss3 , op5 )(bss3 , bss4 , op6 )(bss4 , bss6 , op7 )
(bss7 , bss2 , op8 )(bss2 , bss3 , op9 )
(bss3 , bss6 , op7 )
−2
−1 + 0 − 1 +0 + 0 − 1 +0 − 1 − 1
−1
−1 − 1 − 1
−1 + 0 − 1 +0 + 0 − 1
−2
−1 + 0 − 1
−1
−1 + 0 + 0
−6
−5
−3
−4
= −18
Abbildung 11.3: Berechnung des Gleichheitswertes p von drei Kommunikationsverbindungen
Operationsaufrufe mehrfach auftreten, d. h. wenn Kommunikationsverbindungen Zyklen enthalten. Zyklen entstehen, wenn eine Bausteinschnittstelle mehrfach als aufgerufene Bausteinschnittstelle auftritt, u. U. mit derselben aufgerufenen Operation.
Diese Form der Wiederverwendung wird beim Ausrichten und Berechnen des Gleichheitswertes durch die beiden genannten Regeln ber¨
ucksichtigt. Ohne sie k¨
onnten ungeeignet hohe
Abweichungen, d. h. ungeeignet niedrige Gleichheitswerte, berechnet werden.
11.2.2 Der absolute Heterogenit¨
atsgrad von n Kommunikationsverbindungen
Der Heterogenit¨
atsgrad kann auch f¨
ur mehr als zwei Kommunikationsverbindungen bestimmt
werden. Die Definition und Berechnungsvorschrift f¨
ur den Gleichheitswert p aus Abschnitt
11.2.1 wird dazu folgendermaßen erweitert:
Definition und Berechnungsvorschrift
Definition 11.3 Der absolute Gleichheitswert p von n > 1 Kommunikationsverbindungen
ist ein Maß f¨
ur die Abweichung der Kommunikationsverbindungen hinsichtlich der zugeh¨
origen
Bausteinschnittstellen und der aufgerufenen Operationen.
F¨
ur die Berechnung von p f¨
ur n Kommunikationsverbindungen werden die Regeln aus Abschnitt 11.2.1 durch folgende Erg¨
anzungen allgemeiner gefasst:
1*. Gleichheitswerte werden jeweils f¨
ur Vektoren von n Kommunikationsbeziehungen berechnet. Der Gleichheitswert von n Kommunikationsbeziehungen ist gleich der Summe
der n − 1 paarweisen Gleichheitswerte.
2*. Der Gleichheitswert von zwei L¨
ucken ist 0.
3*. Die Ausrichtung der Kommunikationsverbindungen erfolgt auf der Basis eines n-dimen¨
sionalen W¨
urfels. Die Bewertung der Uberg¨
ange zwischen den benachbarten W¨
urfelelementen erfolgt, wie beim Verfahren f¨
ur zwei Kommunikationsverbindungen, auf der
Basis der berechneten Abweichungen.
4*. F¨
ur die abschließende Ausrichtung entsprechend des g¨
unstigsten Pfades durch den n-dimensionalen W¨
urfel gilt: Bei allen Kommunikationsverbindungen, deren Elemente bei
¨
einem Ubergang
zwischen benachbarten W¨
urfelelementen beibehalten werden, wird eine
L¨
ucke eingef¨
ugt.
Ende — Definition und Berechnungsvorschrift
Abbildung 11.3 zeigt ein Beispiel f¨
ur die Ausrichtung von drei Kommunikationsverbindungen
und die Berechnung des zugeh¨
origen Gleichheitswertes.
177
11 Heterogenit¨
atsbewertung von Kommunikationsverbindungen
Auch die Definition des Heterogenit¨
atsgrades H f¨
ur n Kommunikationsverbindungen erfolgt
auf der Basis des absoluten Gleichheitswertes:
Definition 11.4 Der absolute Heterogenit¨
atsgrad H von n Kommunikationsverbindungen ist gleich dem Betrag ihres absoluten Gleichheitswertes:
H(kv1 , . . . , kvn ) := |p(kv1 , . . . , kvn )|
H: absoluter Heterogenit¨
atsgrad
p : absoluter Gleichheitswert
(11.2)
Ende — Definition und Berechnungsvorschrift
11.2.3 Interpretation des absoluten Heterogenit¨
atsgrades
Der absolute Heterogenit¨
atsgrad H ist stets eine ganze Zahl4 gr¨
oßer oder gleich 0. Sein Betrag kann zun¨
achst nicht als intuitiv verst¨
andliche Kenngr¨
oße interpretiert werden. Er kann
jedoch verwendet werden, um verschiedene alternative Architekturen hinsichtlich ihrer Heterogenit¨
at zu vergleichen. Entsprechend der Grundannahme 2 aus Kapitel 1 ist ein geringerer
Heterogenit¨
atsgrad zu bevorzugen.
Der in Abschnitt 11.3 definierte relative Heterogenit¨
atsgrad und der in Abschnitt 11.4 definierte kostenbewertete Heterogenit¨
atsgrad k¨
onnen intuitiver interpretiert werden.
11.2.4 Problematik der Anwendung des Heterogenit¨
atsgrades
Die Bewertung von Abweichungen von Operationen
Nach Regel 3.3.5 wird jede Abweichung von Bausteinschnittstellen und jede Abweichung
von Operationen mit einer Strafe“ von −1 belegt. Nach der in Abschnitt 7.2.2 definierten
”
Erweiterung des 3LGM2 hinsichtlich der Operationen kann eine Operation immer nur einer einzigen Bausteinschnittstelle zugeordnet werden. Jede Abweichung von Bausteinschnittstellen ist also immer mit einer Abweichung der Operationen verbunden.
Eine Abweichung von Operationen ohne Abweichung der Bausteinschnittstellen wird
durch die genannte Regel mit der H¨
alfte der Strafe“ f¨
ur eine vollst¨
andige Abweichung der
”
Bausteinschnittstellen und der Operationen bewertet. In manchen Szenarios kann eine
geringere Strafe“ f¨
ur Abweichungen der Operationen sinnvoll sein. Diese Problem wird hier
”
nicht weiter behandelt.
Die Ber¨
ucksichtigung gleicher Bausteinschnittstellen
Mit der vorgestellten Berechnungsvorschrift f¨
ur den Heterogenit¨
atsgrad kann zun¨
achst nicht
ber¨
ucksichtigt werden, ob bestimmte verschiedene Bausteinschnittstellen prinzipiell gleich
sind, z. B. durch mehrfache Installation. Dieser Sachverhalt kann auch als Wiederverwendung
betrachtet werden. Er ist insbesondere bei Informationssystemmodellen, die viele gleiche Komponenten beinhalten, relevant.
4
Bei anderen Betr¨
agen f¨
ur die Strafen“ bei Abweichungen von Bausteinschnittstellen oder Operationen
”
kann er zu einer reellen Zahl (gr¨
oßer oder gleich 0) werden.
178
11.3 Der relative Heterogenit¨
atsgrad von Kommunikationsverbindungen
Wenn das 3LGM2 um eine Gleichheitsrelation f¨
ur Bausteinschnittstellen erweitert wird,
k¨
onnen gleiche Installationen von Bausteinschnittstellen beim Bestimmen des Heterogenit¨
atsgrades so behandelt werden, als w¨
are nur eine einzige Installation vorhanden.
Die Abh¨
angigkeit des Heterogenit¨
atsgrades vom Detaillierungsgrad
Bei der Anwendung des Heterogenit¨
atsgrades k¨
onnen f¨
ur ein Informationssystem leicht mehrere unterschiedliche Bewertungen entstehen. Der Wert des Heterogenit¨
atsgrades h¨
angt sehr
stark davon ab, wie fein Kommunikationsverbindungen modelliert wurden. Die detaillierten
Kenntnisse einer bestimmten Kommunikationsverbindung im Vergleich zu m¨
oglicherweise nur
groben Kenntnissen einer anderen Kommunikationsverbindung kann zu unterschiedlich detaillierter Modellierung f¨
uhren. Der Heterogenit¨
atsgrad f¨
ur eine Architektur mit der detaillierter
modellierten Kommunikationsverbindung kann dann allein aufgrund der h¨
oheren Detaillierung
h¨
oher sein als der Heterogenit¨
atsgrad f¨
ur eine Architektur mit Nutzung der nur grob modellierten Kommunikationsverbindung.
Der in den Grunds¨
atzen ordnungsgem¨
aßer Modellierung“ beschriebene Grundsatz der Ver”
gleichbarkeit ([Becker et al. 2000], S. 16) impliziert die Ber¨
ucksichtigung des Detaillierungsgrades bei der Modellierung. Ein allgemeines Vorgehen zur Einhaltung eines bestimmten Detaillierungsgrades wurde bisher jedoch nicht formuliert. Die Angabe einer entsprechenden Vorschrift erfolgt auch in dieser Arbeit nicht.
Der Abschnitt 11.4 beschreibt, wie die Ber¨
ucksichtigung von Kosten u. a. das Problem der
unterschiedlichen Detaillierung beseitigen oder abschw¨
achen kann.
11.3 Der relative Heterogenit¨
atsgrad von Kommunikationsverbindungen
11.3.1 Der relative Heterogenit¨
atsgrad
Der relative Heterogenit¨
atsgrad ist eine Grundlage f¨
ur weiterf¨
uhrende Berechnungen auf der
Basis der bisherigen Definitionen f¨
ur den Heterogenit¨
atsgrad. Er wird in Abschnitt 11.4 f¨
ur die
Definition des kostenbewerteten Heterogenit¨
atsgrades verwendet.
Zur Berechnung des relativen Heterogenit¨
atsgrades wird hier zun¨
achst der relative Gleichheitswert definiert. F¨
ur die Berechnung des relativen Gleichheitswertes werden die bisher definierten Regeln zur Berechnung des absoluten Gleichheitswertes angepasst.
Definition und Berechnungsvorschrift
Definition 11.5 Der relative Gleichheitswert pr von n > 1 Kommunikationsverbindungen
ist die Summe der gemittelten Abweichungen der einzelnen Vektoren von Kommunikationsbeziehungen nach Ausrichtung der Kommunikationsverbindungen.
F¨
ur die Berechnung von pr f¨
ur n Kommunikationsverbindungen werden die Regeln aus den
Abschnitten 11.2.1 und 11.2.2 durch folgende Erg¨
anzungen angepasst:
1# . F¨
ur die Berechnung des relativen Gleichheitswertes
eines einzelnen Vektors von Kommun
nikationsbeziehungen werden die 2 paarweisen Gleichheitswerte addiert; die Sum-
179
11 Heterogenit¨
atsbewertung von Kommunikationsverbindungen
me wird durch die Anzahl der Paare dividiert und mit n − 1 multipliziert:
pr(kb1 , . . . , kbn )
:=
(p1 , . . . , pn )
2
∗ (n − 1)
n
(11.3)
2
2# . Die Summe der relativen Gleichheitswerte der einzelnen Vektoren ergibt den relativen
Gleichheitswert der betrachteten Kommunikationsverbindungen.
Ende — Definition und Berechnungsvorschrift
Die Definition des relativen Heterogenit¨
atsgrades erfolgt analog zur Definition des absoluten
Heterogenit¨
atsgrades auf der Basis des relativen Gleichheitswertes:
Definition 11.6 Der relative Heterogenit¨
atsgrad HR von n Kommunikationsverbindungen ist gleich dem Betrag ihres relativen Gleichheitswertes:
HR(kv1 , . . . , kvn ) := |pr(kv1 , . . . , kvn )|
H: relativer Heterogenit¨
atsgrad
p : relativer Gleichheitswert
(11.4)
Ende — Definition und Berechnungsvorschrift
11.3.2 Interpretation des relativen Heterogenit¨
atsgrades
Der relative Heterogenit¨
atsgrad HR ist stets eine ganze Zahl5 gr¨
oßer oder gleich 0. Mit der
gew¨
ahlten Strafe“ von −1 f¨
ur jede Abweichung von Bausteinschnittstellen oder Operatio”
nen kann er als Sch¨
atzfunktion f¨
ur die Anzahl der Bausteinschnittstellen und der Implementierungen von Operationen verwendet werden, die m¨
oglicherweise durch andere bereits im
Informationssystem vorhandene Bausteinschnittstellen und zugeh¨
orige Implementierungen
von Operationen ersetzt werden k¨
onnen.
Die Bedeutung der Berechnung f¨
ur einen einzelnen Vektor von Kommunikationsbeziehungen
kann folgendermaßen erkl¨
art werden:
1 Der Wert n2 ist die Anzahl der Paare von Kommunikationsbeziehungen. Die Division der einzelnen absoluten Gleichheitswerte der Paare ergibt einen durchschnittlichen
absoluten Gleichheitswert.
2 Ausgehend von der Annahme, dass die bei der Heterogenit¨
atsgradberechnung betrachteten Kommunikationsverbindungen demselben Zweck dienen, kann formuliert werden:
Alle Kommunikationsbeziehungen k¨
onnen durch eine einzige ersetzt werden.“.
”
3 Wenn sich alle Kommunikationsbeziehungen paarweise vollst¨
andig unterscheiden, k¨
onnen theoretisch (n − 1) Bausteinschnittstellen und (n − 1) Operationen weggelassen
werden. Das entspricht einem absoluten Gleichheitswert von −2 ∗ (n − 1); dabei ist −2
der minimale absolute Gleichheitswert von zwei Kommunikationsbeziehungen6.
4 Durch die Multiplikation von n − 1 mit dem durchschnittlichen absoluten Gleichheitswert
(anstelle des maximalen) werden Wiederverwendungen von Operationen und Bausteinschnittstellen ber¨
ucksichtigt.
5
6
Bei anderen Betr¨
agen f¨
ur die Strafen“ bei Abweichungen von Bausteinschnittstellen oder Operationen
”
kann er zu einer reellen Zahl (gr¨
oßer oder gleich 0) werden.
Bei den ersten Kommunikationsbeziehungen der Kommunikationsverbindungen ist entsprechend −3 als minimaler paarweiser absoluter Gleichheitswert zu verrechnen.
180
11.4 Der kostenbewertete Heterogenit¨
atsgrad von Kommunikationsverbindungen
11.4 Der kostenbewertete Heterogenit¨
atsgrad von Kommunikationsverbindungen
11.4.1 Kosten von Kommunikationsverbindungen
Kosten sind das wohl am meisten verwendete Bewertungskriterium f¨
ur viele Sachverhalte. Auch
bei der Bewertung von Informationssystemen werden Kosten oft in den Mittelpunkt gestellt.
Um Kommunikationsverbindungen hinsichtlich ihrer Kosten vergleichen zu k¨
onnen, wird hier
eine weitere Erg¨
anzung der in den Abschnitten 8.6.1 bis 8.6.2 definierten Tupelnotation von
Kommunikationsbeziehungen vorgenommen. Eine Kommunikationsbeziehung kann also als
Quintupel (bss1 , bss2 , op, {vb1 , . . . vbn }, k) aufgefasst werden:
bss1
:=
bss2
:=
op
:=
kb = (bss1 , bss2 , op, hvb1 , . . . vbn i , k(kb)) hvb1 , . . . vbn i:=
k(kb)
:=
aufrufende Bausteinschnittstelle
aufgerufene Bausteinschnittstelle
aufgerufene Operation
Vermittlungsverbindung als Folge der zugeh¨
origen Kommunikationsbeziehungen
Kosten von kb
(11.5)
¨
F¨
ur eine bessere Ubersichtlichkeit
kann, falls die Vermittlungsverbindungen nicht betrachtet
werden sollen, eine verk¨
urzte Notation ohne die Vermittlungsverbindung gew¨
ahlt werden:
kb = (bss1 , bss2 , op, k(kb))
(11.6)
Die Kosten einer Kommunikationsverbindung sind gleich der Summe der Kosten der zugeh¨
origen Kommunikationsbeziehungen:
K(kv)
:=
X
k(kbi )
(11.7)
i=0...L(kv)
11.4.2 Der kostenbewertete Heterogenit¨
atsgrad
Der in diesem Abschnitt vorgestellte kostenbewertete Heterogenit¨
atsgrad f¨
ur Kommunikationsverbindungen kann verwendet werden, um die Wiederverwendung von Integrationstechniken
unter Ber¨
ucksichtigung der mit ihnen verbundenen Kosten zu bewerten.
F¨
ur die Definition des kostenbewerteten Heterogenit¨
atsgrades wird zun¨
achst der kostenbewertete Gleichheitswert eingef¨
uhrt.
Definition und Berechnungsvorschrift
Definition 11.7 Der kostenbewertete Gleichheitswert pk von n > 1 Kommunikationsverbindungen ist ein Maß f¨
ur die Abweichung der Kommunikationsverbindungen hinsichtlich
der zugeh¨
origen Bausteinschnittstellen und der aufgerufenen Operationen unter Ber¨
ucksichtigung der Kosten der einzelnen Kommunikationsbeziehungen.
F¨
ur die Berechnung von pk f¨
ur n Kommunikationsverbindungen werden die Regeln aus den
Abschnitten 11.2.1, 11.2.2 und 11.3 durch folgende Erg¨
anzungen erweitert und ge¨
andert:
1+ . Der kostenbewertete Gleichheitswert wird prinzipiell wie der relative Gleichheitswert
bestimmt (vgl. Abschnitt 11.3). F¨
ur die Berechnung der kostenbewerteten Gleichheits-
181
11 Heterogenit¨
atsbewertung von Kommunikationsverbindungen
werte der einzelnen Vektoren von Kommunikationsbeziehungen werden die in den
folgenden Regeln angegebenen Anpassungen angewendet.
+
ur ein Paar von Kommunikationsbeziehun2 . Jeder absolute Gleichheitswert p(kbi , kbj ) f¨
gen wird durch Division durch den theoretischen maximalen absoluten Gleichheitswert
ptmax f¨
ur ein Paar von Kommunikationsbeziehungen standardisiert:
ps(kbi , kbj )
:=
p(kbi , kbj )
ptmax
(11.8)
Mit den standardisierten Gleichheitswerten f¨
ur die einzelnen Paare wird der standardbasierte relative Gleichheitswert f¨
ur jeden Vektor von Kommunikationsbeziehungen
berechnet:
psr(kb1 , . . . , kbn )
:=
(ps1 , . . . , psn )
2
∗ (n − 1)
n
(11.9)
2
3+ . Jeder der standardbasierten relativen Gleichheitswerte f¨
ur einen Vektor von Kommunikationsbeziehungen wird mit den durchschnittlichen Kosten der zugeh¨
origen Kommunikationsbeziehungen multipliziert. Das Ergebnis ist der kostenbewertete Gleichheitswert f¨
ur den betreffenden Vektor von Kommunikationsbeziehungen:
P
pk(kb1 , . . . , kbn ) := psr(kb1 , . . . , kbn ) ∗
i=1...n
k(kbi )
(11.10)
n
4+ . Die Summe der kostenbewerteten Gleichheitswerte der einzelnen Vektoren ergibt den
kostenbewerteten Gleichheitswert der betrachteten Kommunikationsverbindungen.
Ende — Definition und Berechnungsvorschrift
Der kostenbewertete Heterogenit¨
atsgrad von Kommunikationsverbindungen wird analog zum
absoluten und zum relativen Heterogenit¨
atsgrad definiert:
Definition 11.8 Der kostenbewertete Heterogenit¨
atsgrad HK von n Kommunikationsverbindungen ist gleich dem Betrag ihres kostenbewerteten Gleichheitswertes:
HKkv1,...,kvn := |pkkv1,...,kvn |
HK: kostenbewerteter Heterogenit¨
atsgrad
pk : kostenbewerteter Gleichheitswert
(11.11)
Ende — Definition und Berechnungsvorschrift
11.4.3 Interpretation des kostenbewerteten Heterogenit¨
atsgrades
Der kostenbewertete Heterogenit¨
atsgrad HK ist stets eine Kostenangabe. Mit der in Regel 2+
vorgeschriebenen Standardisierung der Gleichheitswerte f¨
ur Paare von Kommunikationsbeziehungen kann er als Sch¨
atzfunktion f¨
ur die Summe der Kosten der Bausteinschnittstellen
und der Implementierungen von Operationen verwendet werden, die m¨
oglicherweise durch
andere bereits im Informationssystem vorhandene Bausteinschnittstellen und zugeh¨
orige
Implementierungen von Operationen ersetzt werden k¨
onnen.
182
11.4 Der kostenbewertete Heterogenit¨
atsgrad von Kommunikationsverbindungen
Die Bedeutung der Berechnung f¨
ur einen einzelnen Vektor von Kommunikationsbeziehungen kann, ¨
ahnlich der Berechnung des relativen Heterogenit¨
atsgrades, folgendermaßen erkl¨
art
werden:
1 Die Standardisierung der absoluten Gleichheitswerte f¨
ur die einzelnen Paare von Kommunikationsbeziehungen wird wegen der Annahme vorgenommen, dass die Kosten i. d. R.
zwar f¨
ur einzelne Bausteinschnittstellen, aber nicht f¨
ur einzelne Operationen bekannt sind. Eine vollst¨
andige Abweichung von zwei Kommunikationsbeziehungen (standardisierter absoluter Gleichheitswert psr = 2) entspricht also einem einmaligen zus¨
atzlichen Aufkommen der Schnittstellenkosten f¨
ur die zweite Bausteinschnittstelle. Eine
Abweichung nur bez¨
uglich der Operationen entspricht einem nur anteiligen Aufkommen
der Schnittstellenkosten, die f¨
ur die zus¨
atzliche Implementierung der zweiten Operation
entstehen. 2 Der Wert n2 ist die Anzahl der Paare von Kommunikationsbeziehungen. Die Division
der einzelnen standardisierten absoluten Gleichheitswerte durch die Anzahl der Paare
ergibt einen durchschnittlichen standardisierten absoluten Gleichheitswert.
3 Ausgehend von der Annahme, dass die bei der Heterogenit¨
atsgradberechnung betrachteten Kommunikationsverbindungen demselben Zweck dienen, kann formuliert werden:
Alle Kommunikationsbeziehungen k¨
onnen durch eine einzige ersetzt werden.“.
”
4 Wenn sich alle Kommunikationsbeziehungen paarweise vollst¨
andig unterscheiden, k¨
onnen theoretisch (n − 1) Bausteinschnittstellen und (n − 1) Operationen weggelassen
werden. Das entspricht einem Gleichheitswert von −1 ∗ (n − 1); dabei ist −1 der minimale
standardisierte absolute Gleichheitswert von zwei Kommunikationsbeziehungen7.
5 Durch die Multiplikation von n − 1 mit dem durchschnittlichen Gleichheitswert (anstelle
des maximalen) werden Wiederverwendungen von Operationen und Bausteinschnittstellen ber¨
ucksichtigt.
6 Die jeweilige abschließende Multiplikation der durchschnittlichen Kosten f¨
ur eine Kommunikationsbeziehung des betrachteten Vektors f¨
uhrt zum kostenbewerteten Heterogenit¨
atsgrad. Jede vollst¨
andige Abweichung von zwei Kommunikationsbeziehungen f¨
uhrt
dabei zu einem vollst¨
andigen Anrechnen (mit Faktor 1) der durchschnittlichen Kosten.
Jede Abweichung nur bez¨
uglich der Operation f¨
uhrt zu einem anteiligen Anrechnen.
11.4.4 Bemerkungen zum kostenbewerteten Heterogenit¨
atsgrad
Bis auf das Problem der Abh¨
angigkeit von der Detaillierung der Modellierung gelten alle in
Abschnitt 11.2.4 zum absoluten Heterogenit¨
atsgrad genannten Probleme auch f¨
ur den kostenbewerteten Heterogenit¨
atsgrad. Insbesondere die Bewertung der Abweichung bez¨
uglich der
Operation mit der H¨
alfte der Abweichung bez¨
uglich der Bausteinschnittstelle und der
Operation kann bei Bausteinschnittstellen mit vielen Operationen zu schlecht interpretierbaren Ergebnissen f¨
uhren.
Die Unabh¨
angigkeit von der Detaillierung der Modellierung
Der kostenbewertete Heterogenit¨
atsgrad ist, mit der folgenden Voraussetzung, weniger an”
f¨
allig“ f¨
ur unterschiedliche Detaillierung bei den verglichenen Kommunikationsverbindungen:
7
Bei den ersten Kommunikationsbeziehungen der Kommunikationsverbindungen ist entsprechend −3 als minimaler paarweiser Gleichheitswert zu verrechnen.
183
11 Heterogenit¨
atsbewertung von Kommunikationsverbindungen
Hier wird vorausgesetzt, dass eine detailliertere Modellierung zu einer vergr¨
oßerten Anzahl von
Bausteinschnittstellen f¨
uhrt, die jedoch jeweils geringere Kosten verursachen. Die Summe
der Kosten bei detaillierterer Modellierung sollte prinzipiell gleich der Summe der Kosten bei
weniger detaillierter Modellierung sein. Damit wird eine vergr¨
oßerte Anzahl von Bausteinschnittstellen durch geringere Einzelkosten ausgeglichen.
11.5 Ein Anwendungsszenario aus dem Universit¨
atsklinikum Leipzig
Die Anwendung der in diesem Kapitel vorgestellten Kennzahlberechnungen wird hier an dem
bereits in Abschnitt 10.4 vorgestellten Beispielszenario aus dem Universit¨
atsklinikum Leipzig
(UKL) demonstriert. Auch hier werden die alte und die geplante Architektur hinsichtlich der
Kommunikation von Falldaten analysiert und verglichen.
11.5.1 Ermittlung der Kommunikationsverbindungen als Folgen von
Kommunikationsbeziehungen
In Abbildung 11.4 wurden die Kommunikationsbeziehungen der bereits in Abschnitt 10.4
betrachteten Kommunikationsverbindungen mit Tripelnotationen versehen. Diese Notierungen
werden bei der Ausrichtung der Kommunikationsverbindungen verwendet.
Die Bausteinschnittstellen des Kommunikationsservers (Abbildung 11.4a) wurden detaillierter modelliert als die des ORB (Abbildung 11.4b). Wie bereits in Abschnitt 10.4 beschrieben, wurden die IDL-Stubs und Skeletons, die f¨
ur die Kommunikation u
¨ ber den ORB
verwendet werden, f¨
ur den TOS-Modul und auch f¨
ur den PIDS-Modul zu jeweils einer Bausteinschnittstelle zusammengefasst.
In Abschnitt 11.2.4 wurde erl¨
autert, dass ein unterschiedlicher Detaillierungsgrad u. U. zu
schwer interpretierbaren Ergebnissen beim Vergleich von Architekturen f¨
uhren kann. Die im
hier betrachteten Beispiel gegebenen Unterschiede bei der Modellierung k¨
onnen jedoch durch
folgende Argumentation gerechtfertigt werden: Bei einer CORBA-basierten Architektur werden IDL-Stubs und Skeletons i. d. R. gleichzeitig bei der Implementierung generiert. Sie sind
durch die Schnittstellenspezifikation des u
¨ ber sie bereitgestellten Dienstes unmittelbar miteinander verkn¨
upft bzw. voneinander abh¨
angig. Dadurch ist es auch schwer, Schnittstellenkosten getrennt f¨
ur IDL-Stubs und Skeletons anzugeben. Im Gegensatz dazu werden bei einer Kommunikationsserver-basierten Architektur die einzelnen Bausteinschnittstellen des
Kommunikationsservers oft getrennt konfiguriert und verursachen dadurch jeweils eigene Konfigurations- und Wartungskosten. Die getrennten Kosten entstehen z. B. bei der speziellen
Einrichtung des Nachrichtentransfers von und zu den einzelnen Partnersystemen aber auch bei
der internen Konfiguration. Sehr oft werden Nachrichten, die am Kommunikationsserver eingehen, vor der Weiterversendung gefiltert und transformiert. Die Filter und die Transformationen
h¨
angen dabei von den einzelnen Anwendungsbausteinen ab, die die Nachrichten empfangen
sollen.
11.5.2 Kennzahlen zur Heterogenit¨
at f¨
ur das Anwendungsszenario
Die Tripelnotierungen f¨
ur die einzelnen Kommunikationsbeziehungen wurden um zus¨atzliche
vierte Elemente mit Kostenangaben erg¨
anzt und zu Kommunikationsverbindungen zusammengesetzt.
184
11.5 Ein Anwendungsszenario aus dem Universit¨
atsklinikum Leipzig
a)
b)
Bei a) sind die Endpunkte der Kommunikationsverbindungen vom Patientenverwaltungssystem zu
den Ziel“-Anwendungsbausteinen der Falldaten nummeriert. Bei b) sind die Startpunkte der Kom”
munikationsverbindungen zum PIDS-Modul nummeriert. Die Kommunikationsbeziehungen sind mit
Tripelnotationen ensprechend den Ausf¨
uhrungen in Abschnitt 8.6.1 versehen.
Abbildung 11.4: Anwendungsszenario aus dem UKL mit Kommunikationsserver (a) und mit ORB (b); hervorgehoben
sind die Kommunikationsverbindungen zur Verteilung der Falldaten
185
11 Heterogenit¨
atsbewertung von Kommunikationsverbindungen
(s1 , s2 , o1 ,
(s1 , s2 , o1 ,
(s1 , s2 , o1 ,
(s1 , s2 , o1 ,
(s1 , s2 , o1 ,
(s13 , s14 , o12 ,
(s15 , s16 , o13 ,
−33
− 9, 43
−3005, 43e
1000e)
1000e)
1000e)
1000e)
1000e)
800e)
900e)
(s2 , s3 , o2 ,
(s2 , s4 , o3 ,
(s2 , s5 , o4 ,
(s2 , s6 , o5 ,
(s2 , s7 , o6 ,
200e)
200e)
250e)
300e)
200e)
−30
− 8, 57
−938, 07e
(s3 , s8 , o7 ,
(s4 , s9 , o8 ,
(s5 , s10 , o9 ,
(s6 , s11 , o10 ,
(s7 , s12 , o11 ,
2500e)
1800e)
1900e)
3000e)
2500e)
−30
− 8, 57
−9543, 86e
=
−93
=p
=
−26, 57 = pr
= −13487, 36e = pk
a)
(s1 , s1 0, o1 ,
(s2 , s1 0, o2 ,
(s3 , s1 0, o2 ,
(s4 , s5 , o3 , 800e) (s5 , s6 , o4 , 1000e) (s6 , s1 0, o2 ,
(s7 , s1 0, o2 ,
(s8 , s1 0, o2 )
(s9 , s1 0, o2 ,
−18
−12
−27
− 5, 14
− 3, 43
− 7, 71
−195, 43e
−244, 29e
−4883, 00e
3000e)
2000e)
1500e)
1000e)
2000e)
1800e)
2000e)
(s1 0, s1 1, o1 ,
(s1 0, s1 1, o2 ,
(s1 0, s1 1, o2 ,
(s1 0, s1 1, o2
(s1 0, s1 1, o2 ,
(s1 0, s1 1, o2 ,
(s1 0, s1 1, o2 ,
− 6
− 1, 71
−2580, 00e
3000e)
3000e)
3000e)
3000e)
3000e)
3000e)
3000e)
= −63
=p
= −17, 99 = pr
= −7902, 72e = pk
b)
Abbildung 11.5: Ausgerichtete Kommunikationsverbindungen des Anwendungsszenarios; Berechnung der absoluten und
der relativen Gleichheitswerte
Abbildung 11.5 zeigt die Ausrichtungen der Kommunikationsverbindungen und die Ergebnisse der Berechnungen der Gleichheitswerte. Aus den Gleichheitswerten k¨
onnen die Heterogenit¨
atsgrade unmittelbar ermittelt werden. F¨
ur die alte Architektur mit Kommunikationsserver
gilt bez¨
uglich der hier betrachteten Kommunikationsverbindungen:
– H = 93,
– HR = 26, 57,
– HK = 13.487, 36e
F¨
ur die neue Architektur mit ORB gilt bez¨
uglich der hier betrachteten Kommunikationsverbindungen:
– H = 63,
– HR = 17, 99,
– HK = 7.902, 72e
186
Z Abschluss
Z.1 Vorbemerkungen
In den Kapiteln zwischen der Einleitung und dem hier beginnenden Abschluss wurde das Thema der Informationssystemarchitektur aus verschiedenen, jedoch nicht unabh¨
angigen, Blickwinkeln betrachtet. Im Teil I Grundlagen“ wurden Grundlagen zu Integrationsanforderungen,
”
Architekturstandards und Methoden der Gesch¨
aftsprozessmodellierung erarbeitet. In Teil II
Architekturmodellierung“ wurde auf der Basis der Grundlagen ein Metamodell f¨
ur die Mo”
dellierung von Informationssystemen, das 3LGM2 zum 3LGM2A u
berarbeitet.
F¨
u
r
das
3LGM2A
¨
wurden in Teil III Architekturbewertung“ Ans¨
atze zur Bewertung von Informationssystemar”
chitekturen hinsichtlich der Integration entworfen.
Dieses abschließende Kapitel fasst die Ergebnisse der vorliegenden Arbeit mit Bezug zu den
in der Einleitung genannten Zielen und Fragen zusammen.
Z.2 Beantwortung der Fragen
In der Einleitung wurden zu den folgenden Zielen Fragen gestellt:
Ziel Z1 Es soll dargestellt werden, welche Anforderungen bzgl. der Integration von Informationssystemkomponenten typischerweise in Krankenh¨
ausern gestellt werden
und welche Techniken zu ihrer Erf¨
ullung verwendet werden k¨
onnen.
¨
Ziel Z2 Es soll eine vergleichende Ubersicht u
¨ ber Architekturstandards erstellt werden.
¨
Ziel Z3 Es soll eine Uberarbeitung
des 3LGM2 entworfen werden, welche die Modellierung
der Erf¨
ullung von Integrationsanforderungen und die Bewertung der Verwendung
unterschiedlicher Integrationstechniken erlaubt. Dabei sollen vorhandene Architekturstandards ber¨
ucksichtigt werden.
Ziel Z4 Es soll mit Hilfe des u
¨ berarbeiteten 3LGM2 untersucht werden, ob verschiedene
Integrationstechniken ausgetauscht werden k¨
onnen, ohne dass dabei Einbußen an
Funktionalit¨
at entstehen.
Z.2.1 Fragen zu Ziel Z1
F1.1
Welche Anforderungen werden an die Integration von Informationssystemkomponenten
gestellt?
Im Anwendungsbereich des Gesundheitswesens k¨
onnen sehr viele einzelne Integrationsanforderungen gestellt werden. Sie h¨
angen davon ab, welche Aufgaben unter Nutzung und Bearbeitung
welcher Informationen in welchem Zusammenhang zu erledigen sind und welche Werkzeuge daf¨
ur zur Verf¨
ugung stehen.
In Kapitel 2 wurden zur Einteilung der Anforderungen die Anforderungskategorien
187
Z Abschluss
–
–
–
–
–
–
–
physische Integration,
Datenintegration,
funktionale Integration,
semantische Integration,
Kontextintegration,
Pr¨
asentationsintegration und
Zugriffsintegration.
erarbeitet.
¨
Kapitel 9 beschreibt mit dem Dom¨
anenkonzept einen Ansatz zur Uberpr¨
ufung der Erf¨
ullung
von Integrationsanforderungen dieser Kategorien mit Hilfe des 3LGM2A (siehe Antwort zu Frage
F4.2).
F1.2
Welche Techniken k¨
onnen zur Erf¨
ullung der Integrationsanforderungen verwendet werden
und welche Vor- bzw. Nachteile haben sie?
F¨
ur Integrationstechniken extieren sehr viele Standards, die oft nur mit Hilfe von Rahmenwerken f¨
ur die Informationssystemarchitektur verstanden und angewendet werden k¨
onnen. In
Kapitel 4 wurden die Rahmenwerke
–
–
–
–
–
–
–
–
–
–
Referenzmodell f¨
ur die Kopplung offener Systeme (OSI-Referenzmodell),
Referenzmodell f¨
ur offene verteilte Informationsverarbeitung (RM-ODP),
Object Management Architecture (OMA),
Healthcare Information Framework (HIF),
The Open Group Architectural Framework, Version 7, (TOGAF 7),
Zachman-Rahmenwerk,
Architektur integrierter Informationssysteme (ARIS),
Enterprise Application Integration (EAI),
The Open Group Architectural Framework, Version 8, (TOGAF 8) und
Enterprise Application Planning (EAP)
vorgestellt.
Sehr viele Standards f¨
ur Integrationstechniken wurden auf der Basis des OSI-Referenzmodells
entwickelt oder k¨
onnen leicht den Ebenen des OSI-Referenzmodells zugeordnet werden.
¨
Die folgenden Abs¨
atze geben einen beispielhaften Uberblick.
Physische Integration F¨
ur die physische Integration k¨
onnen u. a. die in der Standardreihe
802.X der IEEE spezifizierten Techniken verwendet werden. Die Standards 802.3x spezifizieren
beispielsweise das sogenannte Ethernet, die Standards 802.11x die als Wireless LAN bekannten
Techniken (vgl. Abschnitt 4.2.1).
Datenintegration F¨
ur die Datenintegration k¨
onnen alle Techniken verwendet werden, die
allgemein f¨
ur den (logischen) Datenaustausch vorgesehen sind. Dazu existieren u. a. anwendungsbereichsunabh¨
angige Standards f¨
ur die Dokumenten¨
ubertragung, z. B. HTTP, aber auch
188
Z.2 Beantwortung der Fragen
anwendungsbereichsbezogene Standards f¨
ur Nachrichten- bzw. Dokumentenformate und ggf.
zugeh¨
orige Ereignistypen, z. B HL7. Auch die Kommunikation von Komponenten in einer komponentenorientierten Architektur dient oft der Herstellung von Datenintegration zwischen den
Komponenten. Deshalb k¨
onnen z. B. auch CORBA und DCOM als Standards f¨
ur Datenintegration genannt werden (vgl. Abschnitte 4.2.1, 4.2.3 und 4.3).
Funktionale Integration F¨
ur die funktionale Integration werden Techniken verwendet, die das
Aufrufen von Prozeduren, Funktionen oder, in komponentenorientierter Terminologie, Operationen erm¨
oglichen. Neben bereits ¨
alteren Techniken wie RPC geh¨
oren dazu u. a. ebenfalls die
CORBA und das DCOM (vgl. Abschnitte 4.2.3 und 4.3).
Semantische Integration Wenn semantische Integration einfach als Abgleich von Daten zu
Begriffssystemen oder, allgemeiner, Katalogen verstanden wird, k¨
onnen alle Techniken f¨
ur die
Datenintegration auch f¨
ur semantische Integration verwendet werden. Ein Beispiel f¨
ur h¨
o”
herwertige“ Techniken f¨
ur semantische Integration sind die Dienstgruppe Concept Healthcare
”
Common Services)“ der HISA und Terminologieserver (vgl. Abschnitte 4.2.4 und 4.3).
Kontextintegration F¨
ur Kontextintegration existieren nur wenige bekannte Techniken. Beispiele sind die mit dem Microsoft Internet Explorer verf¨
ugbare Integrierte Windows-Authentifizierung sowie, f¨
ur den Anwendungsbereich des Gesundheitswesen, die Techniken des CCOWStandards (vgl. Abschnitt 4.3).
Pr¨
asentationsintegration Die Herstellung von Pr¨
asentationsintegration ist nicht notwendi¨
gerweise mit der Bereitstellung und ggf. Ubermittlung
von Daten verbunden. Zun¨
achst wird
die einheitliche Gestaltung von Benutzungsschnittstellen gefordert. Beispiele f¨
ur entsprechende Standards sind CUA, Motif, die Apple Human Interface Guidelines oder die Grunds¨
atze
ergonomischer Dialoggestaltung f¨
ur Bildschirmarbeitspl¨
atze (DIN 66234) (vgl. Abschnitt 4.3).
Wenn u
¨ ber funktionale Integration Elemente von Benutzungsschnittstellen wiederverwendet
werden, dann tr¨
agt funktionale Integration zur Pr¨
asentationsintegration bei.
Zugriffsintegration F¨
ur die Zugriffsintegration k¨
onnen alle Techniken zur zentralen Benutzerverwaltung verwendet werden. Dazu werden viele Produkte angeboten, z. B der Active
Directory Server oder der RSA Authentication Service.
Ein Beispiel f¨
ur einen Standard ist die Spezifikation des Kerberos Network Authentication
Service (vgl. Abschnitt 4.2.1).
Bewertungsans¨
atze f¨
ur den Einsatz von Integrationstechniken zur Bestimmung von Vor- und
Nachteilen bestimmter Techniken werden in der Antwort zur Frage F4.2 beschrieben.
189
Z Abschluss
Z.2.2 Fragen zu Ziel Z2
F2.1
Welche bekannten Architekturstandards gibt es und welche Charakteristika haben sie?
Architekturstandards wurden in dieser Arbeit in Kapitel 4 mit Bezug zu verschiedenen Rahmenwerken f¨
ur die Informationssystemarchitektur vorgestellt. Die meisten behandelten Rahmenwerke sind selbst Standards.
Abgrenzung: Mit Architekturstandards sind hier NICHT Standards f¨
ur spezielle Integrationstechniken gemeint.
Die Rahmenwerke wurden in die Kategorien Technische Rahmenwerke und Unternehmensbezogene Rahmenwerke eingeteilt. Die vorgestellten technischen Rahmenwerke sind
–
–
–
–
–
das OSI-Referenzmodell,
das Referenzmodell f¨
ur offene verteilte Informationsverarbeitung (RM-ODP),
die Object Management Architecture (OMA),
das Healthcare Information Framework (HIF) und
(der) The Open Group Architectural Framework, Version 7, (TOGAF 7).
Die vorgestellten unternehmensbezogenen Rahmenwerke sind
–
–
–
–
–
das Zachman-Rahmenwerk,
die Architektur integrierter Informationssysteme (ARIS),
die Enterprise Application Integration (EAI),
(der) The Open Group Architectural Framework, Version 8, (TOGAF 8) und
das Enterprise Application Planning.
Die Rahmenwerke wurden haupts¨
achlich hinsichtlich der Bereitstellung von Begriffsdefinitionen und Metamodellen sowie der Bereitstellung von Informations-, Architektur- und Vorgehens¨
Referenzmodellen betrachtet. Am Ende von Kapitel 4 wurde dazu eine vergleichende Ubersicht
erstellt.
F2.2
Wie stehen die Integrationsanforderungen mit den Architekturstandards in Beziehung?
Architekturstandards werden i. d. R. entworfen, um komplexe Informationssysteme durch Aufteilung in Komponenten besser beherrschen zu k¨
onnen. Die Tatsache, dass die betreffenden
Komponenten zusammenwirken m¨
ussen, d. h. dass Integration gew¨
ahrleistet werden muss,
wird dabei beim Entwurf des Standards durch die Festlegung der Beziehungen zwischen den
Komponenten unmittelbar deutlich.
Vor allem die technischen Rahmenwerke und die zugeh¨
origen Standards f¨
ur einzelne Elemente der Rahmenwerke beschreiben Ans¨
atze zur Realisierung von Kommunikationsbeziehungen
zwischen Komponenten, z. B. durch Spezifikation von Schnittstellen oder von Protokollen f¨
ur
die Kommunikation. Damit werden die konzeptionellen Voraussetzungen f¨
ur die Herstellung
von Integration, d. h. die Erf¨
ullung von Integrationsanforderungen, geschaffen. In der Antwort
zu Frage 1.2 wurden den einzelnen Anforderungskategorien beispielhaft Standards zu Integrationstechniken zugeordnet.
190
Z.2 Beantwortung der Fragen
Die in Abschnitt 4.2 vorgestellten technischen Rahmenwerke wurden, mit Ausnahme von
TOGAF, als Grundlage f¨
ur spezielle Architekturstandards f¨
ur Komponenten und Kommunikationsprotokolle entwickelt. Im Gegensatz dazu helfen TOGAF in der Version 7 und die
vorgestellten unternehmensbezogenen Rahmenwerke, mit der Vielzahl der Integrationsanforderungen und den existierenden technischen L¨
osungen umzugehen.
F2.3
Welchen Integrationstechniken liegen die Architekturstandards zugrunde?
Wie bereits in der Antwort zu Frage F2.2 beschrieben, wurden die meisten der technischen
Rahmenwerke entwickelt, um auf ihrer Basis spezielle Architekturstandards f¨
ur Komponenten
und Kommunikationsprotokolle, d. h. f¨
ur spezielle Integrationstechniken, zu erstellen.
OSI-Referenzmodell Das OSI-Referenzmodell ist die Grundlage f¨
ur viele spezielle Standards
zur physischen Integration, z. B. die IEEE-Standardreihe 802.X, und f¨
ur viele eng mit der
physischen Integration verkn¨
upfte Protokolle f¨
ur den Datenaustausch (vgl. Abschnitt 4.2.1).
RM-ODP Das RM-ODP beschreibt zun¨
achst Grundlagen f¨
ur den Entwurf verteilter Informationssysteme und damit f¨
ur viele Integrationstechniken. Die im RM-ODP beschriebenen
speziellen Funktionen, die in einem verteilten System implementiert sein sollten, k¨
onnen als
spezielle Techniken zur Verwaltung der Verteilung betrachtet werden (vgl. Abschnitt 4.2.2).
OMA Die OMA wurde ebenfalls f¨
ur den Entwurf verteilter Informationssysteme entwickelt.
Sie stellt im Gegensatz zum allgemeiner ausgerichteten RM-ODP den Aspekt der Bereitstellung
von Diensten durch Komponenten und das Aufrufen der Dienste in den Vordergrund. Sie ist
damit zun¨
achst Grundlage f¨
ur funktionale Integration (vgl. Abschnitt 4.2.3).
Funktionale Integration steht in einer Dualit¨
atsbeziehung zu Datenintegration. Gleichzeitig
kann funktionale Integration, wie Datenintegration, zur Erf¨
ullung von Integrationsanforderungen anderer Anforderungskategorien, z. B. semantischer Integration oder Zugriffsintegration,
dienen. Damit k¨
onnen die OMA und die erg¨
anzenden Standards zur Erf¨
ullung von allen Integrationsanforderungen, mit Ausnahme der physischen Integration, beitragen.
Der vermutlich wichtigste erg¨
anzende Standard zur OMA ist die Common Object Request
Broker Architecture (CORBA). Darin wird die zentrale Komponente der OMA, der Object
Request Broker (ORB), spezifiziert. Der ORB ist eine Technik zur Vermittlung der Dienstanforderungen an Komponenten.
Zus¨
atzlich wurden viele erg¨
anzende Standards zu den in der OMA beschriebenen Dienstkategorien erstellt, deren Implementierungen zur Erf¨
ullung vieler Integrationsanforderungen
beitragen k¨
onnen.
HIF Das HIF wurde als Grundlage f¨
ur spezielle Dienstspezifikationen f¨
ur den Anwendungsbereich des Gesundheitswesens entwickelt. Implementierungen der auf der Basis des HIF in
erg¨
anzenden Standards spezifizierten Dienstgruppen k¨
onnen zur Erf¨
ullung mehrerer Integrationsanforderungen beitragen (vgl. Abschnitt 4.2.4).
191
Z Abschluss
TOGAF TOGAF ist ein Rahmenwerk f¨
ur den Entwurf bzw. die Weiterentwicklung von Informationssystemarchitekturen und damit auch f¨
ur die Anwendung von Integrationstechniken.
Die zuvor genannten Rahmenwerke sind Grundlage f¨
ur die Entwicklung weiterer Standards
f¨
ur Integrationstechniken. Im Gegensatz dazu werden in der von der Open Group f¨
ur TOGAF
bereitgestellten Standards Information Base (TOGAF SIB) viele von anderen Organisationen
erstellte Standards zusammengefasst und den Dienstkategorien des TOGAF Technical Reference Model (TOGAF TRM) zugeordnet (vgl. Abschnitt 4.2.5).
Z.2.3 Fragen zu Ziel Z3
F3.1
Wie stehen die in Frage F2.1 genannten Architekturstandards mit dem 3LGM2 in
Beziehung?
Ein Ziel der Entwicklung des 3LGM2 ist die Unterst¨
utzung des strategischen Managements bei
der Auswahl von Integrationstechniken auf der Basis der zugrunde liegenden Standards. Dazu
wurde das 3LGM2 in Kapitel 7 auf der Basis des Kapitel 4 zu Architekturstandards und des
Kapitel 5 zur Gesch¨
aftsprozessmodellierung u
ur eine ausf¨
uhrlichere Zusammen¨ berarbeitet (f¨
¨
fassung der Uberarbeitung
siehe Antwort zur Frage F3.3).
F¨
ur das u
atze zur Architekturbewertung in den Kapi¨ berarbeitete 3LGM2 wurden die Ans¨
teln 9 bis 11 entwickelt. Damit k¨onnen Vergleiche der Anwendung verschiedener Integrationstechniken durchgef¨
uhrt werden.
F3.2
Wie muss das 3LGM2 ¨
uberarbeitet werden, um die in Frage F1.1 genannten
Integrationsanforderungen modellieren zu k¨
onnen?
F¨
ur die Modellierung der Integrationsanforderung semantische Integration wurde in Kapitel 7
die Klasse Begriffssystem in das 3LGM2 eingef¨
uhrt. Mit den zum in Kapitel 9 entwickelten
Dom¨
anenkonzept geh¨
orenden Anforderungsdom¨
anen kann das Bestehen von Integrationsanforderungen zwischen Anwendungsbausteinen ermittelt werden (f¨
ur eine ausf¨
uhrlichere Zusammenfassung zum Dom¨
anenkonzept siehe Beantwortung der Frage F4.2).
Bei der Erstellung des Dom¨
anenkonzeptes wurden die f¨
ur die Architekturmodellierung vor2
¨
genommenen Uberarbeitungen des 3LGM ber¨
ucksichtigt. Sie werden in der folgenden Antwort
zusammengefasst.
F3.3
Wie muss das 3LGM2 ¨
uberarbeitet werden, um die in Frage F1.2 genannten
Integrationstechniken modellieren sowie Vor- und Nachteile bestimmen zu k¨
onnen?
In Kapitel 7 wurde das 3LGM2 zum 3LGM2A u
¨ berarbeitet, um die Modellierung der Anwendung verbreiteter Architekturkonzepte zu erm¨
oglichen. Dazu wurde auf der logischen Werkzeugebene die Klasse Operation eingef¨
uhrt, und die Assoziationsbeziehungen der Klassen f¨
ur
die Integrationsmodellierung wurden u
¨ berarbeitet.
192
Z.2 Beantwortung der Fragen
¨
Die Uberarbeitung
reflektiert das Objekt- bzw. Komponentenkonzept, das haupts¨
achlich im
RM-ODP und in den mit der OMA eng verbundenen Metamodellen Object Model und Compo¨
nent Model beschrieben wird. Uber
das Modellieren der Bereitstellung von Operationen kann
auch die Implementierung von Diensten modelliert werden. Dienste bzw. Dienstkategorien werden u. a. in der OMA und erg¨
anzenden Standards, in der auf dem HIF basierenden Healthcare
Information Systems Architecture, Part I, (HISA) und im TOGAF TRM spezifiziert.
¨
Die Uberarbeitung
stellt eine starke Verallgemeinerung der in den genannten Werken definierten Begriffe f¨
ur die Architekturbeschreibung dar, mit der die M¨
oglichkeit der Beschreibung
bestimmter Details verloren geht. Diese Verallgemeinerung wurde hier akzeptiert, um die Komplexit¨
at des 3LGM2A im Vergleich zum 3LGM2 nicht wesentlich zu erh¨
ohen (vgl. Abschnitte 6.1
und 7.1).
Z.2.4 Fragen zu Ziel Z4
F4.1
Welche Gemeinsamkeiten und welche Unterschiede bestehen zwischen den in Frage F2.1
genannten Architekturstandards?
In Abschnitt 4.6 wurden die in Kapitel 4 vorgestellten Rahmenwerke unter Ber¨
ucksichtigung
einiger weiterer zugeh¨
origer Standards gegen¨
ubergestellt. Die Gegen¨
uberstellung wurde auf der
Basis der zu den Rahmenwerken geh¨
orenden Metamodelle, der Unterscheidungen von Sichtweisen auf die Architektur und der Bereitstellung von Referenzmodellen vorgenommen.
¨
Eine vollst¨
andige Uberf¨
uhrungsvorschrift zwischen einzelnen Metamodellen oder Referenzmodellen im Sinne einer bijektiven Abbildung von Elementen eines Rahmenwerkes oder erg¨
anzender Standards auf Elemente eines anderen Rahmenwerkes oder erg¨
anzenden Standards
kann aufgrund der verschiedenen Schwerpunkte und der damit verbundenen unterschiedlichen
Terminologie nicht angegeben werden.
Gemeinsamkeiten und eine damit verbundene prinzipielle Gleichwertigkeit lassen sich f¨
ur
– zentrale Begriffe des RM-ODP, z. B. Objekt, Schnittstelle oder Ereignis und
– zentrale Begriffe des OMG Object Models und des OMG Component Models
feststellen.
¨
Ahnlichkeiten
k¨
onnen ebenfalls f¨
ur
– die auf der Basis der OMA entwickelten Dienstspezifikationen,
– die auf der Basis des HIF entwickelten HISA-Dienstspezifikationen und
– die Dienstkategorien des TOGAF TRM1
festgestellt werden.
1
Das TOGAF TRM gibt eine textliche funktionale Spezifikation f¨
ur Dienstkategorien an, jedoch keine formale
informationale oder funktionale Spezifikation. Insofern ist die Aussage zur Gleichwertigkeit zu den anderen
Spezifikationen nur bei entsprechender Abstraktion von den Spezifikationsdetails auf allgemeine Angaben zur
Funktionalit¨
at gerechtfertigt.
193
Z Abschluss
F4.2
Wie k¨
onnen die in Frage F2.3 genannten Integrationstechniken ausgetauscht werden und
welche Einbußen oder Gewinne an Funktionalit¨
at entstehen dabei?
In Teil III dieser Arbeit wurden drei Ans¨
atze zur Bewertung der Integration entwickelt. Mit
diesen Ans¨
atzen k¨
onnen konkrete Anwendungen von Integrationstechniken in bestimmten Informationssystemen bewertet und verglichen werden.
F¨
ur die Entwicklung der Bewertungsans¨
atze wurden folgende Grundannahmen getroffen (vgl.
Kapitel 1):
GA1: Bei der Bewertung der Architektur stehen folgende Fragen im Vordergrund:
– Welche Integrationsanforderungen bestehen?
– Sind die Integrationsanforderungen erf¨
ullt?
– Wie groß ist die Abh¨
angigkeit zwischen Anwendungssystemen und wo besteht
Potential zur Verringerung der Abh¨
angigkeit?
– Wie komplex ist die Architektur des Informationssystems und wo besteht Vereinfachungspotential?
GA2: Mit der Anzahl unterschiedlicher verwendeter Integrationstechniken steigt die Komplexit¨
at und sinkt die Beherrschbarkeit eines Informationssystems. Das gilt insbesondere dann, wenn mehrere Integrationstechniken zur Erf¨
ullung derselben Integrationsanforderung(en) angewendet werden.
Die Bewertungsans¨
atze basieren auf dem in Kapitel 6 vorgestellten Metamodell 3LGM2 und
seiner in Kapitel 7 entwickelten Erweiterung zum 3LGM2A . Ihre Ausdrucksf¨
ahigkeit ist daher durch die Vorgaben des 3LGM2A beschr¨
ankt. Diese Beschr¨
ankung wird hier ausdr¨
ucklich
2
akzeptiert, da die Bewertungsans¨
atze, wie auch das 3LGMA , ohne umfassende theoretische
Kenntnisse einer komplexen Modellierungssprache angewendet werden sollen (vgl. Abschnitte 6.1 und 7.1).
1. Mit dem Dom¨
anenkonzept (Kapitel 9) kann in einem 3LGM2A -Modell u
uft werden,
¨ berpr¨
ob Integrationsanforderungen erf¨
ullt sind. Es k¨
onnen Mengen von Anwendungsbausteinen (Dom¨
anen) ermittelt werden, f¨
ur die bestimmte Integrationsanforderungen bestehen
(Anforderungsdom¨
anen), und Mengen von Anwendungsbausteinen, f¨
ur die bestimmte
Integrationsanforderungen erf¨
ullt sind (Kommunikationsdom¨
anen).
Anforderungsdom¨
anen sind auf der Basis der erarbeiteten Anforderungskategorien (vgl.
Antwort zu Frage F1.1) in
–
–
–
–
–
–
Datendom¨
anen,
funktionale Dom¨
anen,
semantische Dom¨
anen,
Kontextdom¨
anen,
Pr¨
asentationsdom¨
anen und
Zugriffsdom¨
anen
unterteilt. Kommunikationsdom¨
anen sind in
¨
– Ubermittlungsdom¨
anen f¨
ur Objekttypen und
– Aufrufdom¨
anen f¨
ur Aufgaben
194
Z.2 Beantwortung der Fragen
¨
¨
unterteilt. Die Ubermittlung
von Objekttypen steht dabei f¨
ur das Ubermitteln
bestimmter Daten zwischen Anwendungsbausteinen, das Aufrufen von Aufgaben steht f¨
ur das
Bereitstellen von Funktionalit¨
at von Anwendungsbausteinen f¨
ur andere Anwendungsbausteine und das Nutzen dieser Funktionalit¨
at durch andere Anwendungsbausteine
(vgl. auch Ende von Abschnitt 7.2.2).
Durch Vergleich der Anforderungsdom¨
anen mit den Kommunikationsdom¨
anen kann die
Erf¨
ullung der Integrationsanforderungen u
uft werden. Abschnitt 9.5 enth¨
alt Bei¨ berpr¨
spiele f¨
ur die Durchf¨
uhrung der Vergleiche und Hinweise zur Interpretation.
2. In Kapitel 10 wurden Kennzahlen zur Abh¨
angigkeit von Anwendungsbausteinen und zur
¨
Bewertung der Qualit¨
at von verteilten Transaktionen erarbeitet. Uber
die vier Kennzahlen
–
–
–
–
informationaler Abh¨
angigkeitsgrad,
funktionaler Abh¨
angigkeitsgrad,
Ausf¨
uhrungsabh¨
angigkeitsgrad und
Transaktionsabh¨
angigkeitsgrad
kann beschrieben werden, wie stark ein Anwendungsbaustein von anderen Anwendungsbausteinen abh¨
angt. Informationale Abh¨
angigkeit ist Abh¨
angigkeit hinsichtlich der
von anderen Anwendungsbausteinen bereitgestellten Daten; funktionale Abh¨
angigkeit
ist Abh¨
angigkeit hinsichtlich der bereitgestellten Operationen. Ausf¨
uhrungsabh¨
angigkeit beschreibt den Sachverhalt, dass ein Anwendungsbaustein bei seiner Ausf¨
uhrung
durch andere Anwendungsbausteine blockiert werden kann; Transaktionsabh¨
angigkeit
beschreibt den Sachverhalt, dass Anwendungsbausteine, die verteilte Transaktionen ausl¨
osen, von der Best¨
atigung der Transaktionsausf¨
uhrung in anderen Anwendungsbausteinen abh¨
angig sind.
Mit der
– Transaktionsst¨
arke
wird bestimmt, wie bei redundanter Speicherung von Informationen die Verteilung von
Daten¨
anderungen abgesichert ist.
3. In Kapitel 11 wurden Kennzahlen f¨
ur die Bewertung der Komplexit¨
at der Integrationsinfrastruktur erarbeitet. Mit Hilfe der drei Kennzahlen
– absoluter Hetererogenit¨
atsgrad,
– relativer Heterogenit¨
atsgrad und
– kostenbewerteter Heterogenit¨
atsgrad
wird beschrieben, wie stark Integrationstechniken in den Kommunikationsverbindungen eines Informationssystems wiederverwendet werden. Dabei wird vorausgesetzt, dass
Integrationstechniken in angemessener Weise u
¨ ber Bausteinschnittstellen, Operationen, Nachrichtentypen, Dokumententypen und Kommunikationsbeziehungen modelliert werden k¨
onnen.
Der relative Heterogenit¨
atsgrad kann als Sch¨
atzfunktion f¨
ur die Anzahl von potientiell
ersetzbaren Bausteinschnittstellen und implementierten Operationen interpretiert
werden. Der kostenbewertete Heterogenit¨
atsgrad kann als Sch¨
atzfunktion f¨
ur die potentiell wegen Heterogenit¨
at unn¨
otig entstehenden Kosten interpretiert werden.
Beim Vergleich von Architekturen mit unterschiedlichen Integrationstechniken kann u
¨ ber die
195
Z Abschluss
Anwendung des Dom¨
anenkonzeptes festgestellt werden, welche Integrationsanforderungen in
den Architekturen erf¨
ullt sind. Die Kennzahlen erm¨
oglichen den Vergleich hinsichtlich der
G¨
ute“ der Integration. Wenn beispielsweise in einem Integrationsszenario die Autonomie, d. h.
”
Unabh¨
angigkeit, von Anwendungsbausteinen wesentliches Merkmal ist, k¨
onnen die genannten
Abh¨
angigkeitsgrade als wesentliche Vergleichskriterien verwendet werden.
Mit Hilfe von hinreichend detaillierten Architektur-Referenzmodellen, in die die Anwendung verschiedener Integrationstechniken hineinmodelliert“ wird, k¨
onnen Integrationstechni”
ken auch unabh¨
angig von konkreten existierenden oder geplanten Informationssystemarchitekturen verglichen werden. Entsprechende Referenzmodelle m¨
ussten alle typischerweise in einem
festzulegenden Anwendungsbereich genutzten Komponenten beinhalten. Weiterhin m¨
ussen die
zugeh¨origen Integationsanforderungen und die im Vordergrund stehenden Bewertungskriterien
festgelegt werden (vgl. Abschnitt 4.6).
Z.3 Diskussion
Z.3.1 Kommentierung der Ergebnisse
In dieser Arbeit wurde ein Ansatz zur Modellierung von Architekturen verschiedener Architekturstile entwickelt. Grundlage daf¨
ur ist das Metamodell 3LGM2 , das f¨
ur die Architektur2
modellierung zum 3LGMA u
¨ berarbeitet wurde.
Beschr¨
ankung der Komplexit¨
at der Modellierung
F¨
ur die Nutzung des 3LGM2A im Informationsmanagement sollten keine ausf¨
uhrlichen Kenntnisse von Architekturstandards vorausgesetzt werden. Gleichzeitig sollte die Komplexit¨
at des
¨
oht werden. Bei der Uberarbeitung
des
3LGM2A im Vergleich zum 3LGM2 nicht wesentlich erh¨
3LGM2 wurden deshalb nur wenige grundlegende Begriffe ber¨
ucksichtigt. Die Auswahl kann
dazu f¨
uhren, dass f¨
ur die Modellierung bestimmter Sachverhalte keine ausdr¨
ucklich daf¨
ur definierten Begriffe zur Verf¨
ugung stehen. Die konsequente Nutzung der zur Verf¨
ugung stehenden
Begriffe, die eine Herausforderung bei der Modelierung darstellt, kann jedoch das Vergleichen
von Architekturen unterschiedlicher Architekturstile oder von speziellen, auf ein bestimmtes
Problem zugeschnittenen Architekturen, erleichtern.
Kategorisierung der Integrationsanforderungen
F¨
ur Informationssystemmodelle auf der Basis des 3LGM2A wurden Ans¨
atze zur Bewertung von
¨
Informationssystemen entwickelt. Das Dom¨
anenkonzept kann zur Uberpr¨
ufung der Erf¨
ullung
von Integrationsanforderungen genutzt werden. Dazu m¨
ussen die bei einem bestimmten Integrationsszenario zu ber¨
ucksichtigenden Anforderungen in die im Grundlagenkapitel zu Integrationsanforderungen erarbeiteten Anforderungskategorien eingeteilt werden, was u. U. zun¨
achst
einen Mehraufwand bedeutet.
Die Kategorien k¨
onnen aber gleichzeitig als Hilfestellung zur systematischen Erarbeitung
der im konkreten Fall bestehenden Integrationsanforderungen genutzt werden. Mit einem Mo¨
dellierungswerkzeug, dass die Uberpr¨
ufung der Erf¨
ullung der Anforderungen nach dem Do¨
m¨
anenkonzept umsetzt, kann die Uberpr¨
ufung dann leicht erfolgen. Voraussetzung ist eine
196
Z.3 Diskussion
angemessene Modellierung der Integrationsinfrastruktur (Bausteinschnittstellen, Operationen
usw.).
Verallgemeinerung durch Kennzahlberechnung
Die ebenfalls f¨
ur die Bewertung erarbeiteten Kennzahlen wurden konzipiert, um Architekturen
hinsichtlich der Abh¨
angigkeit von Anwendungsbausteinen und der Komplexit¨
at der Integrationsinfrastruktur zu vergleichen. Der Vergleich kann dabei auch zwischen einer vorhandenen
¨
Architektur (IST-Zustand) und einem geplanten Zustand nach Uberarbeitung
(SOLL-Zustand)
erfolgen. Einige der Kennzahlen k¨
onnen helfen, den Umfang der m¨
oglicherweise ersetzbaren
Elemente und die durch sie verursachten Kosten abzusch¨
atzen. Bei der Nutzung der Kennzahlen k¨
onnen u. U. spezielle Bedingungen hinsichtlich der Verwendung bestimmter Komponenten nicht ber¨
ucksichtigt werden. Die Nutzung der Berechnungsvorschriften ist implizit mit
einer verallgemeinerten Betrachtung der betrachteten konkreten Architektur verbunden. Das
Ausmaß der Verallgemeinerung wird durch die Ausdrucksf¨
ahigkeit der f¨
ur die Berechnungen
verwendeten Modellierungskonstrukte und zus¨
atzlich durch die beschr¨
ankte Flexibilit¨
at der
Berechnungsvorschriften bestimmt.
Spezifische Probleme der Kennzahlanwendung
Zus¨
atzlich zur Beachtung der mit der Berechnung von Kennzahlen verbundenen Verallgemeinerung sind die f¨
ur die Heterogenit¨
atsgrade angegebenen spezifischen Probleme zu ber¨
ucksichtigen. Dazu geh¨
oren die Abh¨
angigkeit vom Detaillierungsgrad der Modellierung und die
m¨
oglicherweise f¨
ur bestimmte Architekturen ungeeignete Festlegung der Bewertungen von Abweichungen der Bausteinschnittstellen und der Operationen.
Z.3.2 Erf¨
ullung der Ziele
F¨
ur jedes der in der Einleitung der Arbeit gestellten Ziele wurde eine L¨
osung entworfen. Die
L¨
osungen sind
– zu Ziel Z1:
· die Anforderungskategorien f¨
ur Integrationsanforderungen,
· die im Zusammenhang mit Rahmenwerken vorgestellten spezifischen Standards f¨
ur
Integrationstechniken und
¨
· das zur Uberpr¨
ufung der Integrationsanforderungen entworfene Dom¨
anenkonzept;
– zu Ziel Z2:
¨
· die Vorstellung der Architekturstandards und die erstellte vergleichende Ubersicht;
– zu Ziel Z3
¨
· die unternommene Uberarbeitung
des 3LGM2 zum 3LGM2A ;
– zu Ziel Z4
¨
· das Dom¨
anenkonzept zur Uberpr¨
ufung der Erf¨
ullung von Integrationsanforderungen
und
· die Kennzahlen informationaler Abh¨
angigkeitsgrad, funktionaler Abh¨
angigkeitsgrad,
Ausf¨
uhrungsabh¨
angigkeitsgrad und Transaktionsabh¨
angigkeitsgrad,
197
Z Abschluss
· die Kennzahl Transaktionsst¨
arke und
· die Kennzahlen absoluter Heterogenit¨
atsgrad, relativer Heterogenit¨
atsgrad und kostenbewerteter Heterogenit¨
atsgrad.
Die L¨
osungen verallgemeinern, wie im vorhergehenden Abschnitt kommentiert, die Integrationsproblematik durch die Kategorisierung der Integrationsanforderungen, die Anwendung des
3LGM2A und den verallgemeinernden Charakter der Berechnungsvorschriften. Mit dem Verallgemeinern wird die M¨
oglichkeit zum Vergleich verschiedener Architekturen geschaffen; mit der
Akzeptanz der Verallgemeinerung und der Anwendung der der hier vorgestellten Bewertungsans¨
atze entf¨
allt die Notwendigkeit, spezifische Bewertungsans¨
atze f¨
ur konkrete Bewertungen
zu entwerfen.
Z.4 Potential f¨
ur Evaluationen und f¨
ur weiterf¨
uhrende Forschung
Die vorgestellten Bewertungsans¨atze wurden auf Beispiele aus dem Universit¨
atsklinikum Leipzig angewendet. Mit der Anwendung auf andere Informationssysteme muss die allgemeine
Praktikabilit¨
at untersucht werden. Dabei sollten insbesondere auch Informationssysteme, die
moderne Techniken nutzen (z. B. auf der Basis der Grid-Technologie), einbezogen werden.
Es wurde mehrfach auf das Problem der Festlegung der Bewertungen von Abweichungen
zwischen Bausteinschnittstellen und Operationen bei der Berechnung von Heterogenit¨
atsgraden
hingewiesen. Gezielte Studien k¨
onnen wesentlich zur sicheren Festlegung der Bewertungen,
u. U. abh¨
angig von betrachteten Architekturstilen, beitragen.
Die entworfenen Bewertungsans¨
atze k¨
onnen zur Analyse von Informationssystemen mit vielen einzelnen Komponenten und komplexen Integrationsinfrastrukturen beitragen. Große“ In”
formationssysteme, z. B. in regionalen Informationsverb¨
unden, werden oft von mehreren verantwortlichen Einrichtungen betreut und weiterentwickelt. Die f¨
ur die Bewertung notwendigen
Modelle k¨
onnen daher u. U. nur durch paralleles Modellieren an unterschiedlichen Standorten
erstellt werden. Damit entstehen hohe Anforderungen an eine Infrastruktur zur verteilten Modellierung, f¨
ur die geeignete L¨
osungen geschaffen werden m¨
ussen.
198
Anhang A Anforderungskatalog f¨
ur die Informationsverarbeitung im
Krankenhaus (Auszug)
Der Anhang enh¨
alt einen Auszug aus dem Anforderungskatalog f¨
ur die Informationsverarbeitung im Krankenhaus [IMBI/MI 2001], S. 28 ff, der die Integration von Informationssystemkomponenten betrifft.
i
Anhang A Anforderungskatalog f¨
ur die Informationsverarbeitung im Krankenhaus (Auszug)
ii
iii
Anhang A Anforderungskatalog f¨
ur die Informationsverarbeitung im Krankenhaus (Auszug)
iv
Anhang B UML-Diagramme f¨
ur die Ebenen des 3LGM2A
Fachliche Ebene
ist_äquivalent_zu
wird_ausgelöst_durch
0..*
0..*
0..*
0..*
Ereignistyp
0..*
löst_aus
1..*
1..*
bearbeitet
löst_aus1..*
0..*
wird_ausgelöst_durch
1..*
unter_Berück-
greift_zu_auf
sichtigung_von
Zugriffsart: {interpretierend,
bearbeitend}
Begriffssystem
bearbeitet
ist_Teil_von
0..*
0..*
Objekttyp
ist_Teil_von
0..*
0..*
0..*
greift_zu_auf
0..*
wird_erledigt_in
0..*
0..*
Organisationseinheit
Aufgabe
0..*
0..*
erledigt
0..*
Rolle
0..*
ist_Teil_von
v
Anhang B UML-Diagramme f¨
ur die Ebenen des 3LGM2A
Logische Werkzeugebene
0:.*
Begriffssystem
0:.*
Objekttyp
wird_gespeichert_von
wird_gespeichert_von
0..*
0..*
Dokumententyp
rechnerbasierter
Anwendungsbaustein
Customizing: Text
0..*
0..*
0..*
hat_als_Master
papierbasierter
Anwendungsbaustein
wird_gespeichert_von
0..*
0..*
Datenbankverwaltungssystem
0..*
verwaltet_Daten_mit
0..*
0:.*
1
Softwareprodukt
0..*
Standardorganisationsplan (SOP)
0..*
basiert_auf
0..1
basiert_auf
Organisationsplan: Text
0:.*
Nachrichtentyp
0..*
0:.*
0..*
Aufgabe
Anwendungsbaustein
1
0..*
0..*
besitzt
0..*
0..*
0..*
Organisationseinheit
mit_Hilfe_von
Bausteinschnittstelle
Nachrichtentyp /
Dokumenttyp
Benutzungsschnittstelle
mit_Hilfe_von
0..*
greift_zu_auf
0..1
stellt_bereit
Zugr-art: {interpretierend,
bearbeitend}
stellt_bereit
0..*
0..*
0..*
Kommunikationsbeziehung
kann_aufrufen
hat_Parametertyp
hat_Ergebnistyp
vi
0..*
0..*
0..*
0..*
Operation
0..*
Synchronitätsmodus: {synchron, asynchron}
Transakt.-modus:
{Commit erforderlich,
Commit nicht erford.}
wird_vermittelt_über
wird_aktiv_bei
1
1
0..*
löst_aus
0..*
wird_
erledigt_in
wird_erledigt_in
Kommunikationsschnittstelle
0..1
kann_aufrufen
0..* wird_ausgelöst_von
0:.*
0..*
0..*
ist_Teil_von
kann_unterstützen
0..*
0..*
0..*
hat_als_Master
wird_gespeichert_von
wird_transportiert_über
wird_transportiert_über
0..*
kann_unterstützen
0:.*
0:.*
Ereignistyp
0..*
Physische Werkzeugebene
Netztyp
Anwendungsbaustein
0..*
basiert_auf
0..*
basiert_auf
Subnetz
0..*
0..*
Netzprotokoll
0..*
ist_verbunden_mit
0..*
1..*
gehört_zu
1..*
0..*
Physischer Datenverarbeitungsbaustein
0..*
0..*
0..*
hat_Standort
0..1
Standort
0..*
ist_Teil_von
ist_ein
ist_installiert_auf
1
0..1
Bausteintyp
vii
Literaturverzeichnis
[Abowd et al. 1995] Abowd, G., R. Allen and D. Garlan (1995): Formalizing style to understand
descriptions of software architecture. ACM Transactions on Software Engineering and Methodology,
4(4):319–364.
[Alexander 1977] Alexander, C. (1977): A pattern language : towns, buildings, construction. New
York: Oxford University Press.
[Allen 2001] Allen, D. W. (2001): Establishing an EAI Architecture. eAI Journal, pp. 49–50.
[Apple Computer Inc. 1987] Apple Computer Inc. (1987): Apple Human Interface Guidelines:
The Apple Desktop Interface. Addison-Wesley.
[Bachmann et al. 2000] Bachmann, F., L. Bass, J. Carriere, P. Clements, D. Garlan,
J. Ivers, R. Nord and R. Little (2000): Software Architecture Documentation in Practice: Documenting Architectural Layers. Special Report: CMU/SEI-2000-SR-004.
[Balzert 1996] Balzert, H. (1996): Lehrbuch der Software-Technik, vol. 1: Software-Entwicklung.
Heidelberg: Spektrum Akademischer Verlag.
[Becker and Sch¨
utte 1996] Becker, J. and R. Sch¨
utte (1996): Handelsinformationssysteme.
Landsberg: mi Wissenschaft.
[Becker et al. 2000] Becker, J., R. Sch¨
utte, T. Geib and H. Ibershoff (2000): Grunds¨atze ordnungsm¨aßiger Modellierung (GoM). Sachbericht des Forschungsprojektes Grunds¨atze ordnungsm¨a”
ßiger Modellierung“ mit dem F¨orderkennzeichen 01 IS 604 # des Bundesministeriums f¨
ur Bildung
und Forschung. ISBN: 3-540-65993-5.
[Berry and Reeves 1992] Berry, R. E. and C. J. Reeves (1992): The evolution of the Common
User Access Workplace Model. IBM Systems Journal, 31(3):414–428.
[Bloch and Bruce 2004] Bloch, B. and I. Bruce (2004): Working With Web Services and MOM:
The Best of Both Worlds. Business Integration Journal, pp. 76–79.
[BPMI BPML WG 2002] BPMI BPML WG (2002): Business Process Modeling Language. Last
Call Draft of the BPML specification.
[BPMI Notation WG 2004] BPMI Notation WG (2004): Business Process Modeling Notation
(BPMN). Version 1.0.
[Brigl et al. 2004] Brigl, B., A. H¨
aber, T. Wendt and A. Winter (2004): Ein 3LGM2 Modell des
Krankenhausinformationssystems des Universit¨atsklinikums Leipzig und seine Verwertbarkeit f¨
ur das
Informationsmanagement. In Rebstock, M., ed.: Modellierung betrieblicher Informationssysteme MobIS 2004, vol. P-45 of GI-Edition: Lecture Notes in Informatics, pp. 21–41.
[Brigl et al. 2003] Brigl, B., T. Wendt and A. Winter (2003): Modeling interdependencies between business and communication processes in hospitals. In Baud, R., M. Fieschi, P. L. Beux and
P. Ruch, eds.: Proceedings of MIE2003, vol. 95 of Studies in Health Technology and Informatics.
Amsterdam: IOS.
[CCOW 2000a] CCOW (2000a): Health Level-Seven Standard Context Management Specification,
Data Definition: Patient Subject. Version CM-1.2.
[CCOW 2000b] CCOW (2000b): Health Level-Seven Standard Context Management Specification,
Data Definition: User Subject. Version CM-1.2.
ix
Literaturverzeichnis
[CCOW 2000c] CCOW (2000c): Health Level-Seven Standard Context Management Specification,
Technology- and Subject-Independent Component Architecture. Version CM-1.2.
[CEN TC251 1997] CEN TC251 (1997): Healthcare Information System Architecture Part 1 (HISA).
CEN-Standard ENV 12967-1.
[Clegg 2000] Clegg, C. W. (2000): Sociotechnical principles for sytem design. Applied ergonomics,
31:463–477.
[DIN 1988] DIN (1988): Bildschirmarbeitspl¨atze: Grunds¨atze ergonomischer Dialoggestaltung. Berlin.
Beuth. DIN 66 234, Teil 8.
[DoD DISA 1996] DoD DISA (1996): Department of Defense Technical Architecture Framework for
Information Management, Volume 1: Overview. Version 3.0.
[Drosdowski 1994] Drosdowski, G., ed. (1994): Duden, Das große Fremdw¨orterbuch. Mannheim:
Dudenverlag.
[Emmerich 2003] Emmerich, W. (2003): Konstruktion von verteilten Objekten. dpunkt.verlag.
[Ferstl and Sinz 1995] Ferstl, O. K. and E. J. Sinz (1995): Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Gesch¨aftsprozessen. Wirtschaftsinformatik, 37(3):209–220.
[Ferstl and Sinz 2001] Ferstl, O. K. and E. J. Sinz (2001): Grundlagen der Wirtschaftsinformatik.
M¨
unchen: Oldenbourg, 4. Auflage ed. Band 1.
[Gamma et al. 1997] Gamma, E., R. Helm, R. Johnson and J. Vlissides (1997): Entwurfsmuster.
M¨
unchen: Addison-Wesley.
[Garlan 1995] Garlan, D. (1995): What is style? In Proceedings of Dagshtul Workshop on Software
Architecture, pp. 169–183.
[Garlan et al. 1997] Garlan, D., R. T. Monroe and D. Wile (1997): ACME: An Architecture
Description Interchange Language. In Proceedings of CASCON ’97, pp. 169–183.
[Garlan and Shaw 1994] Garlan, D. and M. Shaw (1994): Advances in Software Engineering and
Knowledge Engineering, chap. An Introduction to Software Architecture, pp. 1–39. Series on Software
Engineering and Knowledge Engineering (2). Singapore: World Scientific Publishing Company.
[Hasselbring 2000] Hasselbring, W. (2000): Information System Integration. Communications of
the ACM, 43(6):32–36.
[Haux et al. 1998] Haux, R., A. Lagemann, P. Knaup, P. Schm¨
ucker and A. Winter (1998):
Management von Informationssystemen. Stuttgart: Teubner.
[Haux et al. 2004] Haux, R., A. Winter, E. Ammenwerth and B. Brigl (2004): Strategic Information Management in Hospitals: An Introduction to Hospital Information Systems. Springer.
[Hayne and Pollard 2000] Hayne, S. C. and C. E. Pollard (2000): A comparative analysis of
critical issues facing Canadian information systems personnel: a national and global perspective.
Information & Management, 38:73–86.
[Heimbigner and McLeod 1985] Heimbigner, D. and D. McLeod (1985): A Federated Architecture for Information Management. ACM Transactions on Office Information Systems, 3(3):253–278.
[Hilliard 2000] Hilliard, R. (2000): IEEE-Std-1471-2000 IEEE-Std-1471-2000: Recommended Practice for Architectural Description of Software-Intensive Systems. Internet: http://www.enterprisearchitecture.info/Images/Documents/IEEE%201471-2000.pdf.
[HIMSS/RSNA 2003a] HIMSS/RSNA (2003a): IHE IT Infrastructure Technical Framework, Volume
1 (ITI TF-1): Integration Profiles. Revision 1.0.
[HIMSS/RSNA 2003b] HIMSS/RSNA (2003b): IHE Technical Framework, Volume I: Integration
Profiles. Revision 5.5.
x
Literaturverzeichnis
[HL7 1999] HL7 (1999): Health Level Seven (HL7). Version 2.3.1; Standard der HL7-Organisation;
erh¨altlich f¨
ur Mitglieder u. a. u
¨ ber die HL7-Benutzergruppe Deutschland.
[IDS Scheer AG 2004] IDS Scheer AG (2004): ARIS Rahmenkonzept. Pr¨asentationsfoliensatz.
[IEEE 802.11 WG 2003] IEEE 802.11 WG (2003): 802.11. Local and metropolitan area networks–
Specific requirements. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications. IEEE-Standard 802.11, 1999 Edition (R2003).
[IEEE 802.3 WG 2002] IEEE 802.3 WG (2002): 802.3. Local and metropolitan area networks–
Specific requirements. Part 3: Carrier sense multiple access with collision detection (CSMA/CD)
access method and physical layer specifications. IEEE-Standard 802.3-2002.
[IMBI/MI 2001] IMBI/MI (2001): Anforderungskatalog f¨
ur die Informationsverarbeitung im Krankenhaus. Version 1.0b.
[Information Sciences Institute 1981a] Information Sciences Institute (1981a): Internet
Protocol. RFC 791; erstellt f¨
ur die Defense Advanced Research Projects Agency durch das Information Sciences Institute, University of Southern California.
[Information Sciences Institute 1981b] Information Sciences Institute (1981b): Transmission Control Protocol. RFC 793; erstellt f¨
ur die Defense Advanced Research Projects Agency durch
das Information Sciences Institute, University of Southern California.
[Ingenerf and Diedrich 1997] Ingenerf, J. and T. Diedrich (1997): Notwendigkeit und Funktionalit¨at eines Terminologieservers in der Medizin. K¨
unstliche Intelligenz, 97(3):6–14. Sonderheft
Wissensbasierte Systeme in der Medizin“.
”
[ISO JTC 1 1993] ISO JTC 1 (1993): Information technology – Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s – Part 1: Systems. ISO-Standard
ISO/IEC 11172-1:1993(E).
[ISO JTC 1 1998] ISO JTC 1 (1998): Information technology – 8-bit single-byte coded graphic character sets – Part 1: Latin alphabet No. 1. ISO-Standard ISO/IEC 8859-1:1998(E).
[ISO TC 130 2004] ISO TC 130 (2004): Graphic technology – Prepress digital data exchange – Tag
image file format for image technology (TIFF/IT). ISO-Standard ISO 12639:2004(E).
[ISO/IEC JTC 1 1995] ISO/IEC JTC 1 (1995): ISO/IEC DIS 13235 - ODP Trading Function. ISOStandard ISO/IEC DIS 13235 (Final Draft: 20 June, 1995).
[ISO/IEC JTC 1 1996a] ISO/IEC JTC 1 (1996a): Information technology — Open Distributed Processing — Reference model: Architecture. ISO-Standard ISO/IEC 10746-3: 1996(E).
[ISO/IEC JTC 1 1996b] ISO/IEC JTC 1 (1996b): Information technology — Open Distributed Processing — Reference model: Foundations. ISO-Standard ISO/IEC 10746-2: 1996(E).
[ISO/IEC JTC 1 1996c] ISO/IEC JTC 1 (1996c): Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model. Standard ISO/IEC 7498-1: 1994(E).
[ISO/IEC JTC 1 1998a] ISO/IEC JTC 1 (1998a): Information technology — Open Distributed Processing — Reference model: Architectural semantics. ISO-Standard ISO/IEC 10746-4: 1998(E).
[ISO/IEC JTC 1 1998b] ISO/IEC JTC 1 (1998b): Information technology — Open Distributed Processing — Reference model: Overview. ISO-Standard ISO/IEC 10746-1: 1998(E).
[Juric 2002] Juric, M. B. (2002): EAI and Web Services. eAI Journal, pp. 31–35.
[Keller et al. 1992] Keller, G., M. N¨
uttgens and A.-W. Scheer (1992): Semantische Prozeßmodellierung auf der Grundlage Ereignisgesteuerter Prozeßketten (EPK)“. Ver¨offentlichungen des
”
Instituts f¨
ur Wirtschaftsinformatik (IWi), Universit¨at des Saarlandes. Heft 89.
xi
Literaturverzeichnis
[Langner et al. 1997] Langner, P., C. Schneider and J. Wehler (1997): Prozeßmodellierung mit
ereignisgesteuerten Prozeßketten (EPKs) und Petri-Netzen. Wirtschaftsinformatik, 39(5):479–489.
[Lehmann and Meyer zu Bexten 2002] Lehmann, T. M. and E. Meyer zu Bexten (2002):
Handbuch der Medizinischen Informatik. M¨
unchen: Hanser.
[Leiner et al. 1997] Leiner, F., W. Gaus and R. Haux (1997): Medizinische Dokumentation. Stuttgart: Schattauer. 2. Auflage.
[Linthicum 2000a] Linthicum, D. S. (2000a): Application Servers and EAI. eAI Journal.
[Linthicum 2000b] Linthicum, D. S. (2000b): Enterprise Application Integration. Addison-Wesley.
Internet: http://dbs.uni-leipzig.de/buch/index.html.
[Longo 2001] Longo, J. R. (2001): The ABCs of Enterprise Application Integration. eAI Journal,
pp. 56–58.
[Lublinsky 2002] Lublinsky, B. (2002): Approaches to B2B Integration. eAI Journal, pp. 38–47.
[Lublinsky and Farrel Jr. 2001] Lublinsky, B. and M. Farrel Jr. (2001): Enterprise Architecture and J2EE. eAI Journal, pp. 38–43.
[Lutz 2000] Lutz, J. C. (2000): EAI Architecture Patterns. eAI Journal, pp. 64–73.
[Needleman and Wunsch 1970] Needleman, S. B. and C. D. Wunsch (1970): A general method
applicable to the search for similarities in the amino acid sequences of two proteins. Journal of
Molecular Biology, 48(3):444–453.
[Network Working Group 1989] Network Working Group (1989): Requirements for Internet
Hosts – Communication Layers. RFC 1122.
[Network Working Group 1999] Network Working Group (1999): Hypertext Transfer Protocol – HTTP/1.1. RFC 2616.
[Niemann et al. 2002] Niemann, H., W. Hasselbring, T. Wendt, A. Winter and M. Meierhofer (2002): Kopplungsstrategien f¨
ur Anwendungssysteme im Krankenhaus. Wirtschaftsinformatik,
44(75):425–434.
[Olsen 1995] Olsen, P. S. (1995): Aspects of Integration in HIS. International Journal of Bio-Medical
Computing, 39:53–57.
[OMG 1997] OMG (1997): A Discussion of the Object Management Architecture.
[OMG 2000a] OMG (2000a): Air Traffic Control Specification. Version 1.0.
[OMG 2000b] OMG (2000b): Currency Specification. Version 1.0.
[OMG 2000c] OMG (2000c): Internationalization, Time Operations, and Related Facilities. Version
1.0.
[OMG 2000d] OMG (2000d): Meta Object Facility (MOF) Specification. Version 1.3.
[OMG 2000e] OMG (2000e): Mobile Agent Facility Specification. Version 1.0.
[OMG 2000f] OMG (2000f): Trading Object Service Specification. Version 1.0.
[OMG 2001a] OMG (2001a): Biomolecular Sequence Analysis Specification. Version 1.0.
[OMG 2001b] OMG (2001b): Clinical Observations Access Service Specification. Version 1.0.
[OMG 2001c] OMG (2001c): Person Identification Service (PIDS) Specification. Version 1.1.
[OMG 2001d] OMG (2001d): Resource Access Decision Facility Specification. Version 1.0.
[OMG 2002a] OMG (2002a): CORBA Components. Version 3.0.
xii
Literaturverzeichnis
[OMG 2002b] OMG (2002b): Genomic Maps Specification. Version 1.0.
[OMG 2002c] OMG (2002c): Persistent State Service Specification. Version 2.0.
[OMG 2002d] OMG (2002d): Security Service Specification. Version 1.8.
[OMG 2003a] OMG (2003a): Gene Expression Specification. Version 1.1.
[OMG 2003b] OMG (2003b): MDA Guide. Version 1.0.1.
[OMG 2003c] OMG (2003c): OMG Unified Modeling Language Specification. Version 1.5 (formal/0303-01).
[OMG 2004] OMG (2004): CORBA. Version 3.0.3.
[Pearson 2001] Pearson, W. R. (2001): Protein sequence comparison and Protein evolution (Tutorial - ISMB2000). Internet: http://www.people.virginia.edu/ wrp/papers/ismb2000.pdf.
[Rahm 1994] Rahm, E. (1994): Mehrrechner-Datenbanksysteme: Grundlagen der verteilten und parallelen Datenbankverarbeitung. Bonn: Oldenbourg. Internet: http://dbs.uni-leipzig.de/buch/in
dex.html.
[SAP 2005] SAP (2005): HCM. Systemdokumentation zu SAP R/3 IS-H.
[Scheer 1998a] Scheer, A.-W. (1998a): ARIS - Modellierungsmethoden, Metamodelle, Anwendungen. Berlin: Springer, 3. Auflage ed. Band 2.
[Scheer 1998b] Scheer, A.-W. (1998b): ARIS - Vom Gesch¨aftsprozeß zum Anwendungssystem. Berlin: Springer, 3. Auflage ed. Band 1.
[Scheer et al. 1995] Scheer, A.-W., M. N¨
uttgens and V. Zimmermann (1995): Rahmenkonzept
f¨
ur ein integriertes Gesch¨aftsprozeßmanagement. Wirtschaftsinformatik, 37(5):426–434.
[Schmidt 2002] Schmidt, J. (2002): EAI Principles, Part 3. eAI Journal, p. 48.
[Sch¨
utte 1998] Sch¨
utte, R. (1998): Grunds¨
atze ordnungsm¨assiger Referenzmodellierung: Konstruktion konfigurations- und anpassungsorientierter Modelle. Wiesbaden: Gabler.
[Shaw and Garlan 1995] Shaw, M. and D. Garlan (1995): Computer Science Today: Recent Trends
and Developments, chap. Formulations and Formalisms in Software Architecture, pp. 307–323. Lecture Notes in Computer Science (1000). Springer.
[Shaw and Garlan 1996] Shaw, M. and D. Garlan (1996): Software Architecture. Upper Saddle
River, New Jersey: Prentice Hall.
[Spewak and Hill 1992] Spewak, S. H. and S. C. Hill (1992): Enterprise Architecture Planning.
New York: John Wiley & Sons.
[Stylianou and Kumar 2000] Stylianou, A. C. and R. L. Kumar (2000): An Integrative Framework for IS Quality Management. Communications of the ACM, 43(9):99–104.
[The Open Group 2001] The Open Group (2001): The Open Group Architectural Framework. Internet: http://www.opengroup.org/architecture/togaf7/index7.htm. Version 7.
[The Open Group 2003] The Open Group (2003): The Open Group Architectural Framework. Internet: http://www.opengroup.org/architecture/togaf8/index8.htm. Version 8.
[van Bemmel and Musen 1997] van Bemmel, J. H. and M. A. Musen, eds. (1997): Handbook of
Medical Informatics. Heidelberg: Springer.
[Vossen 2000] Vossen, G. (2000): Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme. M¨
unchen: Oldenbourg. 4. Auflage.
[W3C 2004] W3C (2004): Web Services Description Language (WSDL). Version 2.0, Working Draft
3, August 2004.
xiii
Literaturverzeichnis
[Washburn and Evans 1994] Washburn, K. and J. Evans, eds. (1994): TCP/IP. Bonn: AddisonWesley.
[Wendt et al. 2004] Wendt, T., A. H¨
aber, B. Brigl and A. Winter (2004): Modeling Hospital
Information Systems (Part 2): Using the 3LGM2 Tool for Modeling Patient Record Management.
Methods of Information in Medicine, 43(3):256–267.
[WG 2001] WG, IEEE 802.1 (2001): IEEE Standard for Local and Metropolitan Area Networks:
R
Overview and Architecture. IEEE-Standard 802-2001.
[Winter et al. 2001] Winter, A., B. Brigl and T. Wendt (2001): A UML-based Ontology for
Describing Hospital Information System Architectures. In Patel, V. L., R. Rogers and R. Haux,
eds.: Medinfo 2001, pp. 778–782. Amsterdam: IOS.
[Winter et al. 2003] Winter, A., B. Brigl and T. Wendt (2003): Modeling Hospital Information
Systems (Part 1): The Revised Three-layer Graph-based Meta Model 3LGM2 . Methods of Information
in Medicine, 42(5):544–551.
[Winter and Haux 1995] Winter, A. and R. Haux (1995): A Three-Level Graph-Based Model for
the Management of Hospital Information Systems. Methods of Information in Medicine, 34(4):378–
396.
[Winter et al. 1999] Winter, A., A. Winter, K. Becker, O. Bott, B. Brigl, S. Gr¨
aber,
W. Hasselbring, R. Haux, C. Jostes, O.-S. Penger, H.-U. Prokosch, J. Ritter, R. Sch¨
utte and A. Terstappen (1999): Referenzmodelle f¨
ur die Unterst¨
utzung des Managements von Krankenhausinformationssystemen. Informatik, Biometrie und Epidemiologie in Medizin und Biologie,
30(4):173–189.
[Winter et al. 1998] Winter, A., R. Zimmerling, O. J. Bott, S. Gr¨
aber, W. Hasselbring,
R. Haux, A. Heinrich, R. Jaeger, I. Kock, D. P. F. M¨
oller, O.-S. Penger, J. Ritter,
A. Terstappen and A. Winter (1998): Das Management von Krankenhausinformationssystemen:
Eine Begriffsdefinition. Informatik, Biometrie und Epidemiologie in Medizin und Biologie, 29(2):93–
105.
[X/Open 1995] X/Open (1995): Motif Toolkit API. X/Open Document Number: C320.
[Zachman 1987] Zachman, J. A. (1987): A Framework for Information Systems Architecture. IBM
Systems Journal, 26(3).
[Zachman 1999] Zachman, J. A. (1999): A Framework for Information Systems Architecture. IBM
Systems Journal, 38(2&3):454–470. Reprint.
xiv
Stichwortverzeichnis
1. . . 9
2
3LGM
2, 3, 26, 28, 87–97, 192
¨
Uberarbeitung
des ˜ 99–105
fachliche Ebene 87, 88, 100
Hauptklassen des ˜ 87–92
Klassen f¨
ur die Integrationsmodellierung 92–
95
Klassen f¨
ur die Prozessmodellierung 95
logische Werkzeugebene 87, 88, 100
physische Werkzeugebene 87, 92
3LGM2A 99, 99–114, 192–193
fachliche Ebene 100, 105, 121, 131
logische Werkzeugebene 103, 121, 131, 133
physische Werkzeugebene 121
3LGM 87
802.11x siehe IEEE
802.3 siehe IEEE
802.X siehe IEEE
A
Abh¨angigkeit 157–169, 195
Ausf¨
uhrungs˜ 160–161
funktionale ˜ 159–160
˜sgrad
Ausf¨
uhrungs˜ 160–161, 168, 169, 195
funktionaler ˜ 159–160, 168, 169, 195
informationaler ˜ 159, 167, 168, 195
Transaktions˜ 161, 168, 169, 195
informationale ˜ 159
transaktionale ˜ 161
ACME 27
Aktion 22
Altsystem 60
American Standard Code for Information Interchange 34, 52
Anforderung 2
Integrations˜ 1, 3, 11–19, 35, 38, 46, 48,
53, 54, 129–156, 187–190, 192, 194
Erf¨
ullung von ˜en 143, 129–156
˜skategorie 1, 12
Anforderungsdom¨
ane siehe Dom¨ane
Anwendungsbaustein 12
Anwendungsfall 100
Anwendungsmanagement 22
Anwendungsserver 61
Anwendungssystem 12
Anwendungsszenario 130–133, 163–169, 184–
186
Apple Human Interface Guidelines 54
application server siehe Anwendungsserver
Architektur 21, 24, 99
˜bewertung
Grundannahmen der ˜ 8
˜modell siehe Modell
˜qualit¨at 7
˜-referenzmodell siehe Modell
˜standard siehe Standard
˜stil 2, 22, 24, 27, 28, 30, 95, 97, 99
Architektur eines Informationssystems
siehe
Architektur
Architektur integrierter Informationssysteme 28,
56–59, 75, 190
ARIS-Informationsmodell siehe ARIS-Metamodell
ARIS-Metamodell 59
Metamodell 72, 87
Sichten (Sichtweisen) 56
Architektur-Referenzmodell siehe Modell
Architekturmodell siehe Modell
Architekturmodell im engeren Sinn siehe Modell
Architekturmodell im weiteren Sinn siehe Modell
Architekturmuster f¨
ur EAI siehe Muster
Architekturstandard siehe Standard
Architekturstil siehe Architektur
ARIS siehe Architektur integrierter Informationssysteme
ASCII siehe American Standard Code for Information Interchange
Aufrufdom¨ane siehe Dom¨ane
Ausrichtung 171–177, 179, 184, 186
Aussage 22
B
Begriffssystem 17, 113–114, 136, 192
Bewertungsziel 7
Beziehung 23, 29, 30
xv
Stichwortverzeichnis
BPML
siehe Business Process Modeling Language
Business Process Modeling Language 79–81
C
Carnegie Mellon University 22
School of Computer Science 22
CCOW siehe Clinical Context Object Workgroup
CEN siehe Europ¨aisches Komitee f¨
ur Normung
Clinical Context Object Workgroup siehe Health Level Seven
COM siehe Component Object Model
Comit´e Europ´een de Normalisation siehe Europ¨aisches Komitee f¨
ur Normung
Common Object Request Broker Architecture
siehe Object Management Architecture
Common User Application 54
Component Model 40, 72
Component Object Model 53, 62
Consistent Time
siehe Integrating the Healthcare Enterprise Integrationsprofile: Consistent Time Profile
Continuum siehe The Open Group Architectural Framework
CORBA siehe Common Object Request Broker Architecture
CUA siehe Common User Application
D
Daten 11
Datenbanksystem 157–159
Datendom¨ane siehe Dom¨ane
Datenintegration siehe Integration
Datenmodell
konzeptionelles ˜ 17
logisches ˜ 17
objektorientiertes ˜ 17, 62
relationales ˜ 17, 62
Datenmodellierung
semantische ˜ 17
DCOM siehe Distributed Component Object
Model
Detaillierung 179, 183
Deutsches Institut f¨
ur Normung 54
Dienst 33, 40, 42, 46, 106, 105–107
Anwendungs˜ 106, 107
˜spezifikation 106
Vermittlungs˜ 106, 106, 107
Dienstkategorie siehe Kategorie
DIN siehe Deutsches Institut f¨
ur Normung
xvi
˜ 66234 54
Distributed Component Object Model 53, 62,
106
Dokumentation 2
Dom¨ane 22, 129–156, 194
¨
Ubermittlungs˜
140–142, 150, 152
Anforderungs˜ 129, 133–140, 194
Aufruf˜ 142–143, 147, 154
Daten˜ 133–134, 136, 143, 194
funktionale ˜ 134–136, 145, 194
Kommunikations˜ 129, 140–143, 145, 147,
194
Kontext˜ 136–138, 150, 194
Pr¨asentations˜ 138–140, 194
semantische ˜ 136, 147, 194
Zugriffs˜ 140, 152, 154, 194
E
EAI siehe Enterprise Application Integration
EAP siehe Enterprise Application Planning
Ebene
˜n des 3LGM2 87
EAI-˜n 60
˜n des EAP 68, 69
˜n des HIF 46
Einarbeitungsaufwand 2
EJB siehe Enterprise Java Beans
Elementhierarchie 119
EN
˜ 12967-1 46
˜ 12443 46
Enterprise Application Integration 54, 60–64,
75, 190
˜-Technologie 61
Enterprise Application Planning 68–72
Enterprise Architecture Planning 75
Enterprise Continuum siehe The Open Group
Architectural Framework
Enterprise Java Beans 62
Enterprise User Authentication siehe Integrating the Healthcare Enterprise Integrationsprofile: Enterprise User Authentication
Entit¨at 22
Entwurfsmuster 24, 24, 27
EPK siehe Ereignisgesteuerte Prozessketten
Ereignis 72, 77, 79, 82
˜gesteuerte Prozessketten 32, 77–79, 99
˜typ 41, 79, 83, 99–101, 104, 143
Ereignisgesteuerte Prozessketten siehe Ereignis
EUA siehe Enterprise User Authentication
Stichwortverzeichnis
Europ¨aisches Komitee f¨
ur Normung
31, 46
F
Fehlertoleranz 11
File Transfer Protocol 35, 52
Framework for Information Systems Architecture siehe Zachman-Rahmenwerk
FTP siehe File Transfer Protocol
Funktion 38, 77
funktionale Dom¨ane siehe Dom¨ane
funktionale Integration siehe Integration
G
Genomanalyse 171
Gesch¨aftsprozess 59, 77–83, 100
Gleichheitswert
absoluter ˜ 172, 177, 171–178
kostenbewerteter ˜ 181, 181–182
relativer ˜ 179, 179–180
Grundannahme 8
Grunds¨atze
˜ ergonomischer Dialoggestaltung f¨
ur Bildschirmarbeitspl¨atze 54
˜ ordnungsgem¨aßer Modellierung 179
Gruppe 22
H
H¨
ulle 63
Health Level Seven 106
Clinical Context Object Workgroup 53
Health Level Seven 35, 100, 101
˜ Standard Context Management Specification 53
Healthcare Information Framework 46–49, 72,
74, 190, 191
Ebenen des ˜ 46
Healthcare Information Systems Architecture 46, 48, 72, 106, 108–110
Healthcare Information Systems Architecture siehe Healthcare Information Framework
Heterogenit¨at 171–186
˜sgrad 171–184
absoluter ˜ 175, 178, 171–178, 195
kostenbewerteter ˜ 182, 181–184, 195
relativer ˜ 180, 179–180, 195
Heterogenit¨atsgrad siehe Heterogenit¨at
Hierarchie siehe Elementhierarchie
HIF siehe Healthcare Information Framework
HISA
siehe Healthcare Information Systems
Architecture
HL7 siehe Health Level Seven
HTML 52
HTTP siehe Hypertext Transfer Protocol
Hypertext Transfer Protocol 35, 61
I
IDL siehe Interface Definition Language
IEEE
siehe Institute of Electrical and Electronics Engineers
˜ 802.11x 34
˜ 802.3 34
˜ 802.X 14, 34, 52
˜ 1471 21
IETF siehe Internet Engineering Task Force
IHE siehe Integrating the Healthcare Enterprise
Information 11, 26
˜smodell siehe Modell
˜s-Referenzmodell siehe Modell
Informations-Referenzmodell siehe Modell
Informationsmodell siehe Modell
Informationssystem 12
Informationssystemkomponente 2
Institute of Electrical and Electronics Engineers
34
Integrating the Healthcare Enterprise 12
˜ Integrationsprofile 13
Consistent Time Profile 14
Enterprise User Authentication 19
Patient Identifier Cross-referencing 16
Patient Synchronized Applications 17
Retrieve Information for Display 15
Integration 1, 2, 12
˜sanforderung siehe Anforderung
Daten˜ 1, 12, 14, 35, 46, 143–145, 188
funktionale ˜ 1, 12, 15, 46, 53, 145, 188,
189
horizontale ˜ 60
Kontext˜ 2, 12, 16, 53, 150–152, 188, 189
physische ˜ 12, 14, 35, 129, 188
Pr¨asentations˜ 12, 18, 54, 152, 188, 189
˜squalit¨at 7
semantische ˜ 12, 16, 53, 113, 147–150,
188, 189, 192
˜stechnik 2
˜stechnik 2, 3, 188–196
Zugriffs˜ 12, 19, 152–156, 188, 189
Integrationstechnik siehe Integration
Interaktion 35, 40
Interface Definition Language 41
International Organization for Standardization
22
xvii
Stichwortverzeichnis
Internationale Organisation f¨
ur Standardisierung
31, 32
Internet 61
Internet Engineering Task Force 34
Internet Protocol 34, 52
Interpretation 17
IP siehe Internet Protocol
ISO siehe Internationale Organisation f¨
ur Standardisierung
˜ 9241-10 54
ISO/IEC
˜ 10746-1 35, 36
˜ 10746-2 22, 35, 36, 72, 87
˜ 10746-3 22, 35, 37
˜ 10746-4 35, 37
˜ 13235-1 38, 39
˜ 7498-1 33
˜ 7498-2 33
˜ 7498-3 33
˜ 7498-4 33
˜ 10918 52
J
Java Database Connectivity 62
Java Server Pages 61
JDBC siehe Java Database Connectivity
JPEG 52
JSP siehe Java Server Pages
K
Kategorie
Dienst˜n 47, 51, 52
Schnittstellen˜n 41
˜n von Transaktionsausf¨
uhrungen
siehe
Transaktion
Kategorien von Integrationsanforderungen siehe Anforderungskategorien
Kerberos Network Authentication Service 35
Kommunikation
˜sdom¨ane siehe Dom¨ane
nachrichtenbasierte ˜ 2
˜sverbindung 107, 126–127, 171–186
Formalisierung von ˜en 126–127
Kommunikationsdom¨ane siehe Dom¨ane
Kommunikationsserver 61, 63, 111–112, 184,
186
Kommunikationsstandard siehe Standard
Komplexit¨at 8
Komponente 23, 29, 30, 40, 41, 95, 99, 105
Komponententyp 27, 27, 28, 96
Komposition 22
xviii
Konfiguration 22, 27, 27, 29, 30, 96
Konnektor 95
Konnektorentyp 27, 27, 28, 96
Kontextdom¨ane siehe Dom¨ane
Kontextintegration siehe Integration
Kontextmanager 53
Kontextsynchronisierung 2
konzeptionelles Datenmodell siehe Datenmodell
Kosten
˜ von Kommunikationsbeziehungen 181,
182
˜ von Kommunikationsverbindungen 181
L
legacy system siehe Altsystem
Logik 17
logisches Datenmodell siehe Datenmodell
M
Managementinformation 22
Master Patient Index 63
MDA Guide siehe Model Driven Architecture
Guide
Mengensymbole 120
message broker siehe Kommunkationsserver
message-oriented middleware siehe nachrichtenorientierte Middleware
Metamodell siehe Modell
Middleware
nachrichtenorientierte 61
Model Driven Architecture Guide 43, 45
Sichtweisen 43
Modell 26
Architektur˜ 29, 99
˜ im engeren Sinn 29
˜ im weiteren Sinn 29
Informations˜ 29, 47
Meta˜ 26, 28, 40, 59, 72, 87, 97
Referenz˜ 26, 28
Architektur-˜ 21, 29, 29, 32, 33, 46, 51,
62, 72
Informations-˜ 28, 29, 47
Prozess-˜ 100
Vorgehens-˜ 21, 28, 29, 31, 43, 50, 51,
64, 65, 68
semantisches ˜ 27, 28, 30, 95, 96
Transformation von ˜en 44
MOM siehe message-oriented middleware
Motif 54
Moving Picture Experts Group 35, 52
Stichwortverzeichnis
MPEG siehe Moving Picture Experts Group
Muster 24, 25, 27, 29, 30
Architektur˜ f¨
ur EAI 62
N
nachrichtenbasierte Kommunikation siehe Kommunikation
nachrichtenorientierte Middleware siehe Middleware
Nachrichtentyp 105
Transformation von ˜en 105
Namensgraph 22
Namensraum 22
Needleman-Wunsch-Algorithmus 171, 172, 174
NW-Algorithmus
siehe Needleman-WunschAlgorithmus
O
Object Management Architecture 31, 32, 40–
46, 74, 106, 110–111, 190, 191
Common Object Request Broker Architecture 40, 42, 45, 52, 53, 62, 106, 184
˜ Reference Model 40, 41, 72
Object Management Group 28, 40
˜ Component Model 99, 100
˜ Object Model 99, 102
Object Model 28, 40, 40, 72
Object Request Broker 2, 41, 62, 184, 186
Objekt 22, 35, 40, 41, 72, 99
initiierendes ˜ 22
objektorientiertes Datenmodell siehe Datenmodell
ODBC siehe Open DataBase Connectivity
Offenheit 11
OMA siehe Object Management Architecture
OMG siehe Object Management Group
OMG IDL siehe Interface Definition Language
OMG OMA siehe Object Management Architecture
Open DataBase Connectivity 62
Open Group siehe The Open Group
Operation 40, 99, 102–105
ORB siehe Object Request Broker
OSI-Referenzmodell 22, 32–35, 44, 74, 190, 191
Schichten des ˜s 33
P
Patient Identifier Cross-referencing siehe Integrating the Healthcare Enterprise Integrationsprofile: Patient Identifier Crossreferencing
Patient Synchronized Applications
siehe Integrating the Healthcare Enterprise Integrationsprofile: Patient Synchronized
Applications
Phase 31
˜nmodell der ARIS 59
˜n des EAP 68–72
˜n der TOGAF ADM 50, 65
physische Integration siehe Integration
PIX
siehe Integrating the Healthcare Enterprise Integrationsprofile: Patient Identifier Cross-referencing
Plattform 43–45
Portabilit¨at 22
Pr¨adikat 121–126
Pr¨asentationsdom¨ane siehe Dom¨ane
Pr¨asentationsintegration siehe Integration
Protokoll 34
R
Rahmenwerk 21, 31–73, 190
¨
Ubersicht
u
¨ ber ˜e 73–75
technische ˜e 32–53, 190, 191
unternehmensbezogene ˜e 54–69, 190
Reference Model for Open Distributed Processing siehe Referenzmodell f¨
ur offene
verteilte Informationsverarbeitung
Referenzmodell siehe Modell
Referenzmodell f¨
ur die Kopplung offener Systeme siehe OSI-Referenzmodell
Referenzmodell f¨
ur offene verteilte Informationsverarbeitung
35–39, 44, 74, 87, 99,
100, 190, 191
Trading Function 38, 39
relationales Datenmodell siehe Datenmodell
Remote Function Call 2
Request for Comments 34
791 34
793 34
1122 34
Retrieve Information for Display
siehe Integrating the Healthcare Enterprise Integrationsprofile: Retrieve Information
for Display
RFC siehe Remote Function Call, siehe Request for Comments
RM-ODP siehe Referenzmodell f¨
ur offene verteilte Informationsverarbeitung
xix
Stichwortverzeichnis
Rolle
31
S
Satz 22
Schicht 33, 44
˜en des OSI-Referenzmodells siehe OSIReferenzmodell
Schnittstelle 22, 35, 40, 72, 99, 102–105
Schnittstellenkategorie siehe Kategorie
Schnittstellentyp 27
School of Computer Science
siehe Carnegie
Mellon University
Semantik 27, 30, 96
semantische Datenmodellierung siehe Datenmodellierung
semantische Dom¨ane siehe Dom¨ane
semantische Integration siehe Integration
semantische Integrit¨atsbedingungen 17
Semantisches Objektmodell 81
Sicht 21, 43
˜en der ARIS 56
Sichtweise 31, 36, 43, 56
˜n der ARIS siehe Sichten der ARIS
˜n des MDA Guide 43, 44
˜n des RM-ODP 37
˜n des Zachman-Rahmenwerkes 56
Skalierbarkeit 11
SOM siehe Semantisches Objektmodell
Spezifikation
funktionale ˜ 105
informationale ˜ 105
Standard 32
Architektur˜ 2, 3, 190–193
Kommunikations˜ 35, 105
Standard Context Management Specification siehe Health Level Seven
Stufe 31
Subtyp 22
Synchronit¨atsmodus 104
Syntax 25, 27, 95
T
TAFIM
siehe Technical Architecture Framework for Information Management
Tagged Image File Format 35, 52
TCP siehe Transmission Control Protocol
Technical Architecture Framework for Information Management 49
Telnet 35
Terminologieserver 53
The Open Group 31, 49
xx
The Open Group Architectural Framework 21,
31, 49–53, 65, 66, 68, 74, 75, 192
˜ Architecture Development Method 49,
50, 65
Phasen der ˜ 50, 65
˜ Enterprise Continuum 65, 66
˜ Foundation Architecture 49, 68
˜ Integrated Information Infrastructure Reference Model 68, 68
˜ Resource Base 65
˜ Standards Information Base 51, 52, 68
˜ Technical Reference Model 46, 51, 68,
72
Dienstkategorien des ˜ 51, 52
Einheiten des ˜ 51
˜ Version 7 49–53, 190
˜ Version 8 65, 66, 68, 190
TIFF siehe Tagged Image File Format
TOGAF
siehe The Open Group Architectural Framework
TOGAF ADM
siehe TOGAF Architecture
Development Method
TOGAF Architecture Development Method siehe The Open Group Architectural Framework
TOGAF EC siehe TOGAF Enterprise Continuum
TOGAF Enterprise Continuum siehe The Open
Group Architectural Framework
TOGAF Foundation Architecture siehe The
Open Group Architectural Framework
TOGAF III-RM siehe TOGAF Integrated Information Infrastructure Reference Model
TOGAF Integrated Information Infrastructure
Reference Model siehe The Open Group
Architectural Framework
TOGAF RB siehe TOGAF Resource Base
TOGAF Resource Base siehe The Open Group
Architectural Framework
TOGAF SIB siehe TOGAF Standards Information Base
TOGAF Standards Information Base
siehe
The Open Group Architectural Framework
TOGAF Technical Reference Model siehe The
Open Group Architectural Framework
TOGAF TRM siehe TOGAF Technical Reference Model
TP monitor siehe Transaction Processing Monitor
Trading Function
siehe Referenzmodell f¨
ur
offene verteilte Informationsverarbeitung
Stichwortverzeichnis
Transaction Processing Monitor 62
Transaktion 157–159, 195
Abgleichs˜ 158
˜sausf¨
uhrung 162–163
Kategorien von ˜en 162–163, 168, 169
Kooperations˜ 158
˜sst¨arke 162, 195
einfache ˜ 162, 168, 169
standardisierte ˜ 162, 168, 169
Transaktionsausf¨
uhrung siehe Transaktion
Transaktionsmodus 104
Transaktionsst¨arke siehe Transaktion
Transmission Control Protocol 34, 52
Transparenz 22, 38
Typ 22
U
¨
Ubermittlungsdom¨
ane siehe Dom¨ane
UKL siehe Universit¨atsklinikum Leipzig
UML siehe Unified Modeling Language
Unified Modeling Language 21, 32, 45, 59
Universit¨atsklinikum Leipzig 3, 130, 163
use case siehe Anwendungsfall
V
Verfeinerung 22
Verhalten 22
Vermittlung 126–127
˜stiefe 126–127
˜sverbindung 126
˜sverbindung 174, 175
Versagen 22
vertikale Fragmentierung 60
Vertrag 22
Vorgehens-Referenzmodell siehe Modell
W
Wartbarkeit 8
Wireless LAN 34
Wissen 11, 26
Wrapper siehe H¨
ulle
X
XNFS
52
Z
Zachman-Rahmenwerk 55, 56, 68, 75, 190
Zugriffsdom¨ane siehe Dom¨ane
Zugriffsintegration siehe Integration
xxi
Stichwortverzeichnis
xxii
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising