Interebenen-Beziehungen zwischen statischen Komponenten
Wie sich schon an der einen oder anderen Stelle gezeigt hat, existieren die drei Ebenen nicht
unabhängig voneinander. Die vielfältigen Beziehungen zwischen den Ebenen bezeichnen wir als
Inter-Ebenen-Beziehungen. In den Klassendiagrammen der Ebenen sind sie als gepunktete Klassen
und Assoziationsbeziehungen sichtbar. Sowohl zwischen der Fachlichen Ebene und der Logischen
Werkzeugebene als auch zwischen der Logischen und der Physischen Werkzeugebene können wir
Zusammenhänge feststellen.
Beziehungen zwischen fachlicher Ebene und logischer Werkzeugebene
Aufgabe - Anwendungsbaustein
Innerhalb eines Krankenhauses kann eine Aufgabe unterstützt werden durch
- mehrere Anwendungsbausteine gemeinsam,
- durch ein einzelnen Anwendungsbaustein,
- durch Kombinationen davon.
Dieser Sachverhalt drückt sich in der Anwendungsbausteinkonfiguration aus.
Die Anwendungsbausteinkonfigurationen lassen sich wie folgt ermitteln:
- Welche Anwendungsbausteine sind gemeinsam notwendig, um die Aufgabe unterstützen zu können?
Eine Anwendungsbausteinkonfiguration enthält also alle die Anwendungsbausteine, die zur
Unterstützung der Aufgabe unmittelbar erforderlich sind. Unmittelbar bezieht sich dabei
auf die reine Funktionalität, nicht auf die Lieferung von Daten. Wenn man einen Anwendungsbaustein
aus einer Konfiguration entfernt, wird die Aufgabe nicht mehr unterstützt.
- Welche möglichen Alternativen gibt es zur Unterstützung der Aufgabe?
Eine Aufgabe kann durch mehrere Anwendungsbausteinkonfigurationen unterstützt werden. Wenn
man eine Anwendungsbausteinkonfiguration wegnimmt, kann die Aufgabe trotzdem noch durch eine
der verbleibenden erledigt werden, ggf. unter Einschränkung der Qualität. Wenn dies nicht so
ist, kann dies ein Indiz dafür sein, dass auf der Fachlichen Ebene nicht adäquat (z.B. nicht
fein genug) modelliert wurde.
Abb. 1 zeigt ein Beispiel einer Anwendungsbausteinkonfiguration.
Abb. 1: Anwendungsbausteinkonfigurationen (Beispiel)
Anwendungsbaustein-Konfigurationen können Hinweise auf Redundanzen auf der logischen Werkzeugebene
geben, aber auch Hinweise auf Schwächen im Modell der fachlichen Ebene. Dies wird in den folgenden
Anmerkungen nochmals diskutiert. Abb. 12 zeigt ein Beispiel für Anwendungsbausteinkonfigurationen.
Die Aufgabe PATIENTENAUFNAHME wird unterstützt durch zwei Anwendungsbausteinkonfigurationen.
Die hellgraue besteht aus dem PVS - das allerdings keine eigene Datenbank enthält - und MED DB
das die zentrale Datenbank enthält, in der die Aufnahmedaten gespeichert werden. Die Aufgabe
PATIENTENAUFNAHME kann also nur ausgeführt werden, wenn beide Anwendungsbausteine, PVS und MED
DB verfügbar sind. Die dunkelgraue Anwendungsbausteinkonfiguration besteht aus genau einem
Anwendungsbaustein, der ausreicht, um die Aufgabe PATIENTENAUFNAHME zu unterstützen.
Anmerkungen zu dem Konzept der Anwendungsbausteinkonfigurationen: In der folgenden Abb. 2
sieht es zunächst so aus, als könnte das AB Laboratory das AB Radiology ersetzen. Das dies nicht
so ist, ist offensichtlich. Es liegt also ein Modellierungsproblem vor. Um dies zu beheben,
bieten sich zwei Möglichkeiten an:
- Wir verfeinern auf der fachlichen Ebene die Aufgabe Diagnostik in Labordiagnostik, Radiologiediagnostik und Pathologische Diagnostik. Jede dieser Aufgabe erhält dann den entsprechenden Anwendungsbaustein zugeordnet.
- Wir vergröbern auf der logischen Werkzeugebene und fassen die Anwendungsbausteine für die Diagnostik zu einem Anwendungsbaustein zusammen.
- Eine dritte Möglichkeit ergibt sich daraus, dass man - wie in der aktuellen Version des Metamodells getan - Organisationseinheiten einführt. Berücksichtigt man diese später bei der Zuordnung der Anwendungsbausteinkonfigurationen - so wie im Metamodell vorgeschlagen - so kann man diese Problematik umgehen.
Hieraus kann man sich leicht klarmachen, dass die Verwendung von Anwendungsbausteinkonfigurationen
im Prinzip äquivalent ist zur Vergröberung und Verfeinerung von Anwendungsbausteinen.
Man will mit der Verwendung von Anwendungsbausteinkonfigurationen allerdings umgehen,
'künstliche' Anwendungsbausteine einführen zu müssen und möchte diesen Sachverhalt lieber
explizit als anderes Konzept modellieren.
Abb. 2: Anwendungsbausteinkonfigurationen mit Hinweis auf nicht adäquate Modellierung
Hat man andererseits eine Aufgabe, die tatsächlich alternativ durch zwei Anwendungsbausteine
unterstützt wird (siehe Abb. 3), wird man folgende Überlegungen durchführen müssen:
- Handelt es sich tatsächlich um dieselbe Aufgabe?
- Sind die Alternativen tatsächlich notwendig (beispielsweise aufgrund äußerer Gegebenheiten,
oder weil einer der Anwendungsbausteine noch eine zusätzliche Aufgabe unterstützt)?
Abb. 3: Anwendungsbausteinkonfigurationen Alternativen
Im Beispiel von Abb. 3 sehen wir die Aufgabe Laboratory Services durch zwei Anwendungsbausteine
alternativ unterstützt, die auch noch auf zwei verschiedenen Softwareprodukten basieren
(die Softwareprodukte sind in Klammern angegeben). Hier könnte es aber durchaus sein, dass
einer der Anwendungsbausteine zusätzlich noch in der Lehre eingesetzt wird, also eine weitere
Aufgabe unterstützt. Allerdings müssen wir uns dann fragen, ob nicht wenigsten Anwendungsbausteine
basierend auf dem gleichen Softwareprodukt verwendet werden sollen
Ein weiteres Beispiel ist die Aufgabe Terminplanung. Zwar gibt es z.B. sowohl im Rahmen der
OP-Planung eine Terminplanung als auch in einer Radiologischen Abteilung. Die entsprechenden
Anwendungsbausteine können einander aber nicht ersetzen. Offenbar muss daher die Aufgabe
Terminplanung verfeinert werden, oder als Teilaufgaben der Aufgaben OP-Planung und Radiologische
Dienste verstanden werden. Entfernt man sich aber vom abteilungsorientierten Denken hin zum
diensteorientierten Denken, so kann es tatsächlich einen generischen Dienst Terminplanung geben,
der je nachdem wo er verwendet wird, unterschiedlich arbeitet.
There are some other important inter-layer-relationships between concepts of the
domain and the logical tool layer which we will shortly describe in the following:
Einem Objekttyp kann zugeordnet werden, welches Datenbanksystem / welche Dokumentensammlung für diesen Objekttyp Master
ist (Beziehung hat_als_Master). Daten zu diesem Objekttypen dürfen ausschließlich in
diesem 'Master-Datenbanksystem' / dieser 'Master-Dokumentensammlung' eingefügt, geändert
oder gelöscht werden. Alle anderen Datenbanksysteme / Dokumentensammlungen, die ebenfalls
Daten zu diesen Objekttyp speichern, müssen über Kommunikation zwischen den
entsprechenden Anwendungsbausteinen ihre Datenbestände mit diesem Datenbanksystem /
Dokumentensammlung abgleichen, wenn Daten geändert, hinzugefügt oder gelöscht
werden, da sonst die Datenintegrität nicht gewährleistet ist. Bei Dokumentensammlungen
ist dies natürlich besonders problematisch!.
Objekttypen können logisch repräsentiert werden durch Datensatztypen, durch Dokumententypen und
durch Nachrichtentypen. Datensatztypen beschreiben welche Informationen repräsentiert als
Objekttypen in einem Datenbanksystem gespeichert werden. Dokumententypen beschreiben, welche
Informationen repräsentiert als Objekttypen in einer Dokumentensammlung gespeichert, und welche
Informationen über eine Kommunikationsverbindung transportiert werden. Ein Nachrichtentyp
beschreibt welche Informationen bei nachrichtenbasierter Kommunikation transportiert werden.
Ein Softwareprodukt unterstützt die Durchführung bestimmter Aufgaben. Entsprechend einer
bestimmten Parametrierung kann es aber sein, dass ein auf einem bestimmten Softwareprodukt
basierender Anwendungsbaustein nicht alle diese Aufgaben unterstützt. Diese Beziehung beschreibt
also nicht, welche Aufgaben ein Anwendungsbaustein basierend auf einem Softwareprodukt tatsächlich
unterstützt, sondern lediglich das Potential, das ein bestimmtes Softwareprodukt bietet.
Aufgabe - Ereignis
Die Beendigung einer Aktivität einer Aufgabe kann ein Ereignis eines bestimmten Ereignistyps
auslösen, das wiederum das Versenden einer Nachricht eines bestimmten Nachrichtentyps steuert.
Diese Beziehung ermöglicht es insbesondere nachrichtenbasierte Kommunikation zu beschreiben.
Beziehungen zwischen logischer Werkzeugebene und physischer Werkzeugebene
Ein rechnerbasierter Anwendungsbaustein kann installiert sein auf:
- mehrere physischen Datenverarbeitungsbausteinen gemeinsam,
- auf einem einzelnen physischen Datenverarbeitungsbausteinen,
- auf Kombinationen davon.
Dieser Sachverhalt drückt sich in der Datenverarbeitungsbaustein-Konfiguration aus.
Die Datenverarbeitungsbaustein-Konfigurationen lassen sich wie folgt ermitteln:
- Welche Datenverarbeitungsbausteine sind gemeinsam notwendig, um den Anwendungsbaustein installieren zu können?
Eine Datenverarbeitungsbaustein-Konfiguration enthält also alle die Datenverarbeitungsbausteine,
die zur Installation des Anwendungsbausteins erforderlich sind. Wenn man einen
Datenverarbeitungsbaustein aus einer Konfiguration entfernt, ist der Anwendungsbaustein nicht mehr
nutzbar.
- Welche möglichen Alternativen gibt es zur Nutzung eines Anwendungsbausteins?
Ein Anwendungsbaustein kann durch mehrere Datenverarbeitungsbaustein-Konfigurationen nutzbar
gemacht werden. Wenn man eine Datenverarbeitungsbaustein-Konfiguration wegnimmt, kann der
Anwendungsbaustein trotzdem noch durch eine der verbleibenden genutzt werden, ggf. unter
Einschränkung der Qualität. Dies ist dann nicht der Fall, wenn ein Datenverarbeitungsbaustein
ausfällt, der in beiden Konfigurationen enthalten ist.
Abb. 4: Datenverarbeitungsbaustein-Konfigurationen (Beispiel)
In unserem Beispiel in Abb. 4 gibt es für den Anwendungsbaustein WARD zwei alternative
Konfigurationen. Fällt beispielsweise der PDVB WARD PC1 aus, so kann zwar mit Konfiguration 1
nicht mehr gearbeitet werden, aber mit Konfiguration 2. Fällt dagegen der PDVB DB Server aus,
so ist keine Konfiguration mehr nutzbar.