Medizinische Fakultät

Transkript

1 IMISE-REPORTS Herausgegeben vn Prfessr Dr. Markus Löffler A. Winter, L. Ißler, F. Jahn, A. Strübing, T. Wendt Das Drei-Ebenen-Metamdell für die Mdellierung und Beschreibung vn Infrmatinssystemen (3LGM² V3) IMISE-REPORT Nr. 1/2010 Medizinische Fakultät

2 IMPRESSUM Herausgeber: Prf. Dr. Markus Löffler Redakteur: Franziska Jahn Institut für Medizinische Infrmatik, Statistik und Epidemilgie (IMISE) Härtelstr. 16/18, Leipzig Tel.: (0341) , Fax (0341) Internet: Druck des Einbandes und Bindung: Buch- und Offsetdruckerei Herbert Kirsten Redaktinsschluss: IMISE 2010 Alle Rechte vrbehalten. Nachdruck nur mit ausdrücklicher Genehmigung des Herausgebers und mit Quellenangabe gestattet. ISSN

3 Inhaltsverzeichnis A EINLEITUNG... 3 B A.A PROBLEMATIK... 3 A.B ZIEL DER ARBEIT... 5 A.C AUFBAU DER ARBEIT... 5 DREI GEGENSTANDSEBENEN EINES INFORMATIONSSYSTEMS (DREI-EBENEN- METAMODELL)... 6 C UML-KLASSENDIAGRAMME ZUR BESCHREIBUNG DES DREI-EBENEN-METAMODELLS... 8 C.A KLASSEN... 8 C.B ASSOZIATIONEN... 9 C.C ASSOZIATIONSKLASSEN... 9 C.D AGGREGATION UND KOMPOSITION ALS SPEZIELLE ASSOZIATIONEN... 9 C.E BEDINGUNGEN D UMSETZUNG DES DREI-EBENEN-METAMODELLS IM 3LGM²-BAUKASTEN E DAS DREI-EBENEN-METAMODELL 3LGM² ZUR BESCHREIBUNG VON INFORMATIONSSYSTEMEN E.A BASIS, ERWEITERUNGEN UND MODIFIKATIONEN DES METAMODELLS E.B DIE BASIS DES DREI-EBENEN-METAMODELLS: 3LGM²-B E.B.A Überblick E.B.B Fachliche Ebene E.B.C Zentrale Begriffe der Lgischen und Physischen Werkzeugebene E.B.D Lgische Werkzeugebene E.B.E Physische Werkzeugebene E.C ERWEITERUNGEN DES METAMODELLS BZW. MODIFIKATIONEN DES METAMODELLS E.C.A Nachrichtenrientierte Kmmunikatin mit Nachrichtentypen: 3LGM²-M E.C.B Servicerientierte Kmmunikatin: 3LGM²-S F ANFORDERUNGEN AN DEN 3LGM²-BAUKASTEN F.A DARSTELLUNG VON 3LGM²-MODELLEN IM 3LGM²-BAUKASTEN F.A.A Baumansicht F.A.B Grafische Einzelebenenansicht F.A.C Grafische 3-Ebenen-Ansicht F.A.D Matrixsicht F.A.E Eigenschaftsdialge F.B AKTUELLE VERSION DES 3LGM²-BAUKASTENS F.C ANFORDERUNGEN AN DEN 3LGM²-BAUKASTEN AUS DEM METAMODELL F.C.A Anfrderungen seitens der Elementklassen F.D HANDHABUNG DES BASIS-METAMODELLS UND ERWEITERUNGEN DES METAMODELLS F.E KONVERTIERUNG VON MODELLEN AUF DER BASIS VON METAMODELL V1.X ZU MODELLEN AUF DER BASIS VON 3LGM² F.E.A Allgemein F.E.B Lgische Werkzeugebene F.E.C Physische Werkzeugebene F.F KONVERTIERUNG ZWISCHEN DEN METAMODELLEN VON 3LGM² F.G ASSOZIATIONSKLASSEN DES METAMODELLS IM 3LGM²-BAUKASTEN G LITERATUR H STICHWORTVERZEICHNIS... 84

4 A Einleitung I DANKSAGUNG J HINWEISE

5 A Einleitung A Einleitung A.A Prblematik Krankenhäuser sind Dienstleistungsunternehmen, die sich durch eine sehr hetergene Unternehmensstruktur auszeichnen. Ein Krankenhaus ist aus einer Vielzahl vn Organisatinseinheiten aufgebaut, die zur Unterstützung ihrer Infrmatinsverarbeitung unterschiedlichste rechnerbasierte und nicht-rechnerbasierte Werkzeuge benötigen. Neben den klassischen Organisatinseinheiten jedes Unternehmens wie Buchhaltung, Persnalverwaltung der Bestellwesen sind es insbesndere die Statinen und Ambulanzen swie die medizinischen Leistungsstellen, die je nach ihrer Aufgabe Bilder der Bildsequenzen (z. B. in der Radilgie), Signale (z. B. in der EKG-Abteilung) der Textinfrmatin zu verarbeiten haben. Die Menge der anfallenden Daten variiert swhl hinsichtlich der Anzahl der Parameter als auch hinsichtlich der Sequenz der Parameter. Der Behandlungsprzess für einen Patienten gestaltet sich individuell und ist vn vielen Faktren abhängig, die zum Teil nicht im Vraus planbar sind. Es ist daher eine hhe Interperabilität zwischen den am Behandlungsprzess beteiligten Organisatinseinheiten (interne Kmmunikatin) ntwendig. Dies gilt auch für die externe Kmmunikatin mit anderen an der Behandlung des Patienten beteiligten Einrichtungen (z. B. Versicherungen, niedergelassene Ärzte, andere Krankenhäuser der Nachsrgeeinrichtungen). Da Gesundheit und Leben eines Patienten im Krankenhaus vn den zur Behandlung vrliegenden Infrmatinen und daher vm Infrmatinssystem abhängig sind, ergibt sich eine besndere Srgfaltspflicht bei der Infrmatinsverarbeitung und beim Infrmatinsmanagement. Auch wenn mittlerweile ein Grßteil der Aufgaben eines Krankenhauses durch rechnerbasierte Werkzeuge unterstützt werden kann, hat sich gezeigt, dass Krankenhausinfrmatinssysteme nicht als abgegrenzte rechnerunterstützte Systeme, sndern als szi-technisches System aufzufassen sind ([1], [2]). Definitin: Krankenhausinfrmatinssystem (KIS) Ein Krankenhausinfrmatinssystem ist das szi-technische Teilsystem eines Krankenhauses, welches alle datenverarbeitenden Przesse und die an ihnen beteiligten menschlichen und maschinellen Handlungsträger in ihrer datenverarbeitenden 1 Rlle umfasst. Smit sind Krankenhausinfrmatinssysteme zugleich Teilsystem des Krankenhauses und spiegeln seine Hetergenität entsprechend wider. Aufgrund der unterschiedlichen Anfrderungen an die Werkzeuge zur Infrmatinsverarbeitung basieren diese häufig auf unterschiedlichsten Hardware-, Sftware- und anderen Prdukten verschiedenster Hersteller. Hinzu kmmt, dass Krankenhausinfrmatinssysteme histrisch wachsen, s dass es neben mdernen datenverarbeitenden Werkzeugen immer auch sgenannte 'Altsysteme' (legacy systems; vgl. [3]) geben wird. Es kann nicht davn ausgegangen werden, dass alle datenverarbeitenden Werkzeuge eines Krankenhausinfrmatinssystems zu einem Zeitpunkt kmplett ausgetauscht werden (können). Das bisher Gesagte gilt in ähnlicher Frm nicht nur für Krankenhäuser mit ihren Krankenhausinfrmatinssystemen, sndern für alle Organisatinen (Unternehmen, Einrichtungen, Verbände,...) des Gesundheitswesens der gar anderer Branchen. Der Begriff des Krankenhausinfrmatinssystems kann wie flgt verallgemeinert werden [4]: Definitin: Infrmatinssystem (IS) Ein Infrmatinssystem ist das szi-technische Teilsystem einer Organisatin, welches alle datenverarbeitenden Przesse und die an ihnen beteiligten menschlichen und maschinellen Handlungsträger in ihrer datenverarbeitenden Rlle umfasst. Damit sind Krankenhausinfrmatinssysteme die Infrmatinssysteme vn Krankenhäusern. Um die Hetergenität eines Infrmatinssystems beherrschen zu können, muss das Infrmatinsmanagement Infrmatinssysteme beschreiben, d. h. mdellieren können. Geeignete Mdelle sllten in der Lage sein, beispielsweise flgende Fragen des Infrmatinsmanagements zu beantwrten: 1 Auch wenn es üblich ist, vn Infrmatinssystemen zu sprechen, werden in diesen Systemen nicht Infrmatinen, sndern Daten, welche Infrmatinen repräsentieren, verarbeitet. Wir wllen daher hier wieder den scheinbar veralteten, aber richtigeren Begriff der Datenverarbeitung verwenden. 3

6 A Einleitung Welche Aufgaben vn Medizinern unterstützt ein bestimmter Klinischer Arbeitsplatz auf einer bestimmten Statin in unserem Krankenhaus? Wie viele verschiedene Anwendungen brauchen die Mediziner, um ihre Arbeit auf Statin erledigen zu können? Welche Anwendung wird für die Anfrderungserstellung und die Darstellung vn Befunden am Klinischen Arbeitsplatz genutzt? Wer ist der Hersteller der entsprechenden Sftware, welches Datenbankverwaltungssystem wird genutzt und welche Server werden in Anspruch genmmen? Bei der Kmmunikatin zwischen der Datenbank auf dem Server und dem Klinischen Arbeitsplatz treten manchmal Fehler aufgrund vn Zeitüberschreitungen auf. Welche Netzwerkkmpnenten könnten diese Fehler verursachen? Welche Schnittstellen zum Labrinfrmatinssystem werden für die Kmmunikatin vn Anfrderungen und Befunden genutzt? Wird HL7 als Prtkll für die Server-Server-Kmmunikatin genutzt der ist eine prprietäre Client-basierte Schnittstelle zum Intranetserver des Labrs installiert? Wie wird im letzteren Fall visuelle Integratin [5] garantiert? Zu welcher Netzwerkdmäne gehört der Klinische Arbeitsplatz und wer ist der verantwrtliche Dmänen-Administratr? Um einen weiteren klinischen Arbeitsplatz auf der Statin zu realisieren, sll ein zusätzlicher PC installiert werden. Welche Stecker, Kabel und Schnittstellenkarten sind ntwendig, um den PC mit dem Netzwerk zu verbinden? In welcher Frm müssen Infrmatinen zwischen welchen Anwendungssystemen auf welchen Kmmunikatinswegen transprtiert werden, wenn eine Flge bestimmter Aufgaben erledigt werden muss? Werden auf einem Kmmunikatinsweg die Infrmatinen nur mit Hilfe elektrnischer Nachrichten der auch durch Dkumente auf gegenständlichen Datenträgern (z. B. Papier, Film, CD) transprtiert. Zwischen welchen Geräten der Orten können Daten hne den Transprt bestimmter gegenständlicher Datenträger übermittelt werden (z. B. über ein Kabelnetz der über ein Funknetz) und w ist das nicht möglich? Für den Fall, dass eine Datenübertragungsverbindung getrennt wird: Bei welchem Anwendungssystem kann dann ein Client- PC nicht mehr auf einen der Server über eine nicht-gegenständliche, signalbasierte Verbindung zugreifen? Sind alle Clients aller Anwendungssysteme mit ihren Servern verbunden? Auf welchen Geräten der an welchen Orten werden Daten in welcher Frm gespeichert bzw. gelagert? Welche Hardware ist vrhanden und w befindet sie sich? Bezgen auf knkrete Anwendungsfälle sllte ein Mdell beispielsweise flgende Fragen beantwrten können: Fragen eines Mitarbeiters im Bereitschaftsdienst der IT-Abteilung: Welche Anwendungssysteme waren auf dem Statinscmputer der Urlgie installiert und welche speziellen Installatinsparameter sind anzugeben, wenn die unwiderruflich defekte Festplatte des PCs durch eine neue ersetzt wurde? Welche Anwendungssysteme und damit verbunden welche Unternehmensaufgaben sind krankenhausweit betrffen, wenn ein zentraler Server ausfällt? Welche Abteilungen des Krankenhauses sind in einem slchen Fall zu benachrichtigen und unter welcher Rufnummer ist der zuständige Mitarbeiter der die beauftragte Servicefirma auch an Wchenenden erreichbar? Fragen vr der Neueinführung eines Digitalen Archivs: Ist ein Referenzmdell verfügbar, in welchem die Aufgaben, die ein digitales Archiv erfüllen muss, beschrieben sind und das für die Erstellung eines Sllmdells verwendet werden kann? Welche Aufgaben aus dem Bereich der digitalen Archivierung werden bereits durch rechnerbasierte Anwendungssysteme ausgeführt? Welche im Referenzmdell beschriebenen Aufgaben werden ggf. nicht gefrdert? Welche Aufgaben sllen ggf. zusätzlich erfüllt werden? Welche rechnerbasierten Anwendungssysteme mit Bezug zur digitalen Archivierung sind im eigenen Krankenhaus im Einsatz? Welche Schnittstellen sind vrhanden? Wie sieht die physische Werkzeugebene (Server, PCs, Netzkmpnenten etc.) des eigenen Krankenhauses aus? 4

7 A Einleitung A.B Ziel der Arbeit Vrrangiges Ziel dieser Arbeit ist es, die für das Infrmatinsmanagement wesentlichen Kmpnenten eines Infrmatinssystems zu identifizieren und sie zusammen mit ihren Beziehungen und Abhängigkeiten in einem Metamdell zusammenzufassen. Dabei wird gezielt der Mdellbegriff vn SCHÜTTE verwendet: Ein Mdell ist das Ergebnis einer Knstruktin eines Mdellierers, der für Mdellnutzer Elemente eines Systems zu einer Zeit als relevant mit Hilfe einer Sprache deklariert. [6]. Das Metamdell sll es als ermöglichen, möglichst s detailliert (der eben nicht-detailliert) beschreiben zu können, wie es für die entsprechenden Zwecke relevant ist. Gleichzeitig sll in dieser Arbeit auch der krrekte und zweckmäßige Gebrauch der Metamdell-Knstrukte bei der 3LGM²-Mdellierung vermittelt werden. Innerhalb dieser Vrgehensmdelle wird insbesndere auch auf die 3LGM²- Mdellierung aktueller Trends in der IT, wie z. B. Virtualisierung der service-rientierte Architekturen, eingegangen. Darüber hinaus sll auch die praktische Relevanz der 3LGM²-Mdellierung verdeutlicht werden, indem Fragen des Infrmatinsmanagements, die sich mit Hilfe des 3LGM² bzw. des 3LGM²-Baukastens analysieren lassen, identifiziert werden. A.C Aufbau der Arbeit Kapitel B führt die drei Gegenstandsebenen des Drei-Ebenen-Metamdells ein. In Kapitel C wird erklärt, welche Knstrukte der Unified Mdeling Language (UML) benutzt wurden, um die Elemente auf den Gegenstandsebenen und deren Beziehungen untereinander zu beschreiben. Um die ausführliche Beschreibung des Drei-Ebenen-Mdells in Kapitel E zu verstehen, ist es nötig, den grundsätzlichen Aufbau des 3LGM²-Baukastens zu kennen. Der 3LGM²- Baukasten, der die Erstellung 3LGM²-knfrmer Mdelle vn Infrmatinssystemen unterstützt, wird in Kapitel D eingeführt. Kapitel E stellt das Metamdell 3LGM² vr, welches aus dem 3LGM²-B (Basis-Metamdell) swie den Erweiterungen und Mdifikatinen 3LGM²-M (Metamdell für nachrichtenbasierte/messagebasierte Kmmunikatin) und 3LGM²-S (Metamdell für diensterientierte/servicerientierte Kmmunikatin) besteht. Dabei werden die vrgestellten Mdellierungsknstrukte anhand eines durchgängigen, praxisnahen Beispiels erklärt. Das Beispielmdell beschreibt ein Infrmatinssystem der Radilgieabteilung eines Krankenhauses. Die Kapitel E.C.A-8, E.C.B-12 und E.C.B-13 beschreiben die Knvertierungsmöglichkeiten zwischen 3LGM²-B, 3LGM²-M und 3LGM²-S. Kapitel F stellt die Anfrderungen an den 3LGM²-Baukasten zusammen, die für diese Versin des Metamdells (3LGM² V3) erfüllt sein müssen. In Kapitel F.E wird beschrieben, wie Mdelle aus dem bisherigen Metamdell in das neue Metamdell knvertiert werden können. 5

8 B Drei Gegenstandsebenen eines Infrmatinssystems (Drei-Ebenen-Metamdell) B Drei Gegenstandsebenen eines Infrmatinssystems (Drei-Ebenen-Metamdell) Das Metamdell zur Beschreibung vn Infrmatinssystemen knüpft an das in [7] veröffentlichte Drei-Ebenen-Mdell und das in [8] weiterentwickelte Drei-Ebenen-Metamdell an. Dieses bietet ein Grundgerüst vn Begriffen, die zur Beschreibung statischer Strukturen vn Infrmatinssystemen geeignet sind. Mit der hier vrgestellten Versin 3 des Metamdells kann sich der Mdellierer zwischen einer Basismdellierung (3LGM²-B), der spezielleren Mdellierung der nachrichtenrientierten Kmmunikatin (3LGM²-M) der der Mdellierung der servicerientierten Kmmunikatin (3LGM²-S) entscheiden. 3LGM²-B, das zunächst beschrieben wird, bildet dabei die Grundlage, um die Erweiterungen und Mdifikatinen in 3LGM²-M und 3LGM²-S zu verstehen. Abbildung 1: Die Gegenstandsebenen des 3LGM² - Der 3LGM²- Twer Die in 3LGM² verwendeten Knzepte lassen sich, wie es beispielsweise auch mit dem in [9] vrgestellten generischen Architekturrahmen für Infrmatinssysteme vrgeschlagen wird, Gegenstandsebenen zurdnen. Wir unterscheiden eine Fachliche Ebene, eine Lgische Werkzeugebene und eine Physische Werkzeugebene: Fachliche Ebene: Mit den Knzepten der fachlichen Gegenstandsebene kann eine Organisatin anhand ihrer Aufgaben beschrieben werden. Im Rahmen der Erfüllung der Aufgaben werden Infrmatinen über Objekte verwendet und auch geschaffen (vgl. auch [10]). Infrmatinen über Objekte liegen in Frm vn Merkmalen vr. Objekte mit gleichen Merkmalsarten werden zu Objekttypen zusammengefasst. Innerhalb vn Przessen können Aufgaben, die Infrmatinen über Objekte nacheinander bearbeiten und interpretieren, in eine lgische und zeitliche Reihenflge eingerdnet werden. Zur Fachlichen Ebene gehört auch, die Struktur der Organisatin, als ihre Gliederung in Organisatinseinheiten zu beschreiben. 6

9 B Drei Gegenstandsebenen eines Infrmatinssystems (Drei-Ebenen-Metamdell) Lgische Werkzeugebene: In dieser Gegenstandsebene lässt sich darstellen, welche lgischen Werkzeuge, die hier als Anwendungsbausteine bezeichnet werden, eine Organisatin zur Erfüllung ihrer Aufgaben einsetzt. Es wird beschrieben, wie diese miteinander kmmunizieren müssen, damit der auf der Fachlichen Ebene beschriebene Zugriff auf Infrmatinen gewährleistet ist. Es wird ebenfalls dargestellt, in welchen Anwendungsbausteinen Infrmatinen über Objekte als Daten gespeichert werden. Physische Werkzeugebene: Mit Hilfe der Begriffe der Physischen Werkzeugebene kann man beschreiben, welche Physischen Datenverarbeitungssysteme eine Organisatin einsetzt, und wie diese miteinander vernetzt sein müssen, damit die Kmmunikatin der auf der Lgischen Werkzeugebene beschriebenen Anwendungssysteme gewährleistet ist. 7

10 C UML-Klassendiagramme zur Beschreibung des Drei-Ebenen-Metamdells C UML-Klassendiagramme zur Beschreibung des Drei- Ebenen-Metamdells Das Metamdell 3LGM² wird mit Hilfe vn Klassendiagrammen der Unified Mdeling Language (UML) (siehe z. B. [11, 12]) frmalisiert. Dabei werden flgende UML-Knzepte (mit den angegebenen, ggf. vm Standard abweichenden Interpretatinen) verwendet: Abbildung 2: UML-Knzepte im 3LGM²-Metamdell. Assziatinsklasse Attribute Assziatinsklasse Attribute Klasse * Name Name Attribute Klasse 2 einfache Assziatin Attribute Klasse 1 * <<rdered>> * Name Name Attribute Klasse 2 1..* Name Aggregatin Attribute Klasse * Name Kmpsitin Attribute 1..* Klasse Name 1 Name Abbildung 3: Assziatinsarten im 3LGM²-Metamdell C.A Klassen Eine Klasse beschreibt die Attribute und Operatinen einer Menge gleichartiger Objekte. Jede Klasse besitzt einen eindeutigen Klassennamen. Klassen können abstrakt sein. Vn abstrakten Klassen können in einem knkreten Mdell keine Instanzen gebildet werden. Der Name abstrakter Klassen ist kursiv gestellt. Abstrakte Klassen besitzen mindestens eine nichtabstrakte Unterklasse. Unterklassen ergeben sich als Spezialisierung einer anderen Klasse, zu der eine Generalisierungsbeziehung besteht. Sie erhalten alle Eigenschaften ihrer Oberklasse und können durch weitere Attribute und Assziatinen näher beschrieben werden. Beispiele für Klassen im 3LGM² sind Aufgabe (siehe E.B.B-1), Anwendungsbaustein (siehe E.B.D-1), Physisches Datenverarbeitungssystem (siehe E.B.E-1). 8

11 C UML-Klassendiagramme zur Beschreibung des Drei-Ebenen-Metamdells C.B Assziatinen Alle im Metamdell 3LGM² verwendeten Arten vn Assziatinen beschreiben nach den üblichen UML- Knventinen Beziehungen zwischen Klassen. Klassen können mit sich selbst über eine Assziatin in Beziehung stehen. Knkrete Instanzen einer slchen Klasse können aber nur mit anderen Instanzen dieser Klasse in Beziehung stehen und niemals mit sich selbst. Jede Assziatin besitzt zwei gerichtete Namen. Der Name am Ende einer Assziatin beschreibt, wie die gegenüberliegende Klasse zu der Klasse an dem Ende in Beziehung steht. Alle Assziatinen sind in beide Richtungen navigierbar und können durch eine Zeichenkette der Frm Klasse 1 Name Klasse 2 eindeutig gerichtet beschrieben werden. Klasse 1 und Klasse 2 sind dabei die Namen der in Beziehung stehenden Klassen und Name ist der entsprechende gerichtete Name der Assziatin. Bei jeder Assziatinsart sind immer an beiden Enden die Multiplizitäten angegeben. Die Multiplizitätsangabe an einem Ende einer Assziatin zeigt an, mit wie vielen Elementen der Klasse an dem Ende ein Element der gegenüberliegenden Klasse minimal verbunden sein muss und maximal verbunden sein kann. Bei allen Assziatinen (außer mit Steretyp <<rdered>>) kann es nur eine Verbindung derselben Art zwischen zwei identischen Instanzen geben. Ein Beispiel für eine Assziatin im 3LGM² sind die Beziehungen benötigt für Funktinalität und benötigt für Speicherung zwischen Anwendungsbaustein und Physischem Datenverarbeitungssystem (siehe E.B.D- 1.9). Für Assziatinen des Steretyps <<rdered>> gilt, dass für wenigstens eine der durch diese Assziatin verbundenen Klassen die Reihenflge der Assziatinen dieser Art eine Bedeutung hat. Für welche der jeweils zwei miteinander verbundenen Klassen das gilt, geht aus dem Kntext des Metamdells hervr. Über Assziatinen mit dem Steretyp <<rdered>> können abweichend vn allen anderen Assziatinsarten dieselben zwei Instanzen vn Klassen mehrfach miteinander verbunden sein. Przesse (siehe E.B.B-6) besitzen im 3LGM² eine Assziatin des Steretyps <<rdered>> zu Aufgaben. C.C Assziatinsklassen Eine Assziatin kann eine Assziatinsklasse sein, wenn die Assziatin selbst durch Attribute der eigene Assziatinen näher beschrieben werden sll. Beispiel für eine Assziatinsklasse im 3LGM² ist die Klasse Kmmunikatinsverbindung (siehe E.B.D-3), zwischen Sende- und Empfangsschnittstelle. C.D Aggregatin und Kmpsitin als spezielle Assziatinen Im Drei-Ebenen-Metamdell werden die UML-Knzepte der Aggregatin und der Kmpsitin ausschließlich genutzt, um Beziehungen vn Klassen zu sich selbst zu beschreiben. Dieses Kapitel erläutert den Unterschied zwischen dem Gebrauch vn Kmpsitin und Aggregatin in 3LGM². Es werden die Begriffe Unterelement und Gruppenelement verwendet, um Instanzen vn einer Klasse zu beschreiben, die mit anderen Instanzen dieser Klasse über eine Aggregatin der Kmpsitin verbunden sind. Einem Gruppenelement können mehrere Unterelemente zugerdnet werden, Gruppenelemente können wiederum selbst Unterelement eines anderen Gruppenelements sein. Über das UML-Knzept der Aggregatin wird ausgedrückt, dass die Unterelemente eine spezielle Ausprägung des Gruppenelements repräsentieren. Z. B. kann der Gruppenbjekttyp Befund die unterschiedlichen Ausprägungen Radilgischer Befund und Labrbefund als Unterbjekttypen besitzen. Man könnte die Unterelemente auch als Alternativen des Gruppenelements beschreiben. Diese Unterelemente werden im Flgenden als spezialisierte Elemente bezeichnet. Bei der Verwendung einer Aggregatin im Metamdell wird die Unterscheidung des Gruppenelements in seine Unterelemente als Spezialisierung und das Verallgemeinern der Unterelemente zum Gruppenelement als Generalisierung bezeichnet. Bei einer Spezialisierung in einem knkreten Mdell erhalten bzw. erben alle Unterelemente autmatisch die Verbindungseigenschaften der Gruppenelemente. Dies bedeutet, dass die knkreten Assziatinen vn Gruppenelementen in einem Mdell 9

12 C UML-Klassendiagramme zur Beschreibung des Drei-Ebenen-Metamdells auch für Unterelemente gelten. Dabei kann Mehrfachvererbung zugelassen sein, als ein Element kann mehrere Gruppenelemente besitzen und deren Eigenschaften erben, wenn die maximale Kardinalität der Aggregatin für Gruppenelemente größer als 1 ist. Anders als bei den Verbindungseigenschaften werden Attributwerte eines Gruppenelements nicht auf die ihm untergerdneten Elemente übertragen, sndern müssen für diese selbst festgelegt werden. Über das UML-Knzept der Kmpsitin wird ausgedrückt, welche verschiedenen Teile sich zu einem Ganzen zusammenfügen lassen, als z. B. welche Unteraufgaben zusammen die Gruppenaufgabe Patientenaufnahme bilden. Das Unterelement ist hierbei als echter Teil des Gruppenelementes zu verstehen und wird smit auch als Teilelement bezeichnet. Dieses Aufspalten vn Gruppenelementen in Teilelemente wird im Flgenden Zerlegung genannt. Die Umkehrrichtung der Zerlegung, als das Zusammenfügen vn Unterelementen zu einem Gruppenelement wird im Flgenden als Kmpsitin bezeichnet. Zerlegungsbeziehungen sind in den Metamdelldiagrammen vn den Unterelementen zum Gruppenelement mit ist Teil vn und vm Gruppenelement zu den Unterelementen mit hat Teil benannt. Bei Zerlegungen ist Vererbung vn den Gruppenelementen an die Unterelemente nicht in jedem Fall möglich. Deshalb wird für jede Elementklasse, bei der eine Zerlegung möglich ist, im Einzelnen definiert, welche Assziatinen vn Gruppenelementen an Unterelemente vererbt werden. Nicht für alle Elementklassen ist Spezialisierung der Zerlegung möglich. Flgende Tabelle gibt einen Überblick aller Elementklassen bei denen mindestens eine Frm möglich ist. Elementklasse Spezialisierung Zerlegung Verweis auf Text Objekttyp x x E.B.B-1 Aufgabe x x E.B.B-2 Organisatinseinheit x E.B.B-5 Anwendungsbaustein x E.B.D-1 Physisches Datenverarbeitungssystem x E.B.E-1 Geräteklasse x E.B.E-2 Standrt x E.B.E-3 Knkrete Elemente dürfen nicht zirkulär über Aggregatinen der Kmpsitinen verbunden sein. D h. ein Element darf weder sich selbst nch ein anderes Unterelement besitzen, das direkt der über Beziehungen zu anderen Elementen bereits sein Gruppenelement ist. Bei allen Aggregatinen und Kmpsitinen können Unterelemente in einem knkreten Mdell in ihrer Darstellung und inhaltlichen Interpretatin ausgeblendet werden. Dabei werden alle Verbindungseigenschaften der Unterelemente für die Dauer des Ausblendens den Gruppenelementen zugerechnet. Dieses Vrgehen entspricht einer Generalisierung der Aggregatin auf Mdellebene, da im jeweiligen Kntext nicht relevante Detailinfrmatin verbrgen werden kann. In diesem Dkument wird dieses Ausblenden der Unterelemente als Vergröbern und das Wiedereinblenden der Unterelemente als Verfeinern bezeichnet. C.E Bedingungen Eine Bedingung ist eine Zusicherung bzw. Integritätsregel. In einem metamdellknfrmen Mdell müssen alle Bedingungen eingehalten werden. Zur besseren Lesbarkeit sind alle Bedingungen in 3LGM² semifrmal spezifiziert. 10

13 D Umsetzung des Drei-Ebenen-Metamdells im 3LGM²-Baukasten D Umsetzung des Drei-Ebenen-Metamdells im 3LGM²- Baukasten Mit der aktuell verfügbaren Sftware 3LGM²-Baukasten lassen sich in Bezug auf das in [8] veröffentlichte Metamdell 3LGM² V1.01 3LGM²-knfrme Mdelle vn Infrmatinssystemen erstellen. Da in den flgenden Abschnitten häufig auf spezifische Anfrderungen an das Mdellierungswerkzeug zur Erstellung vn Mdellen mit dem neuen, in diesem Dkument beschriebenen Metamdell eingegangen wird, sll hier kurz auf die wichtigsten Bestandteile des bestehenden 3LGM²-Baukastens eingegangen werden (siehe Abbildung 4): Der Mdellbrwser: Im Mdellbrwser sieht man die mmentan geöffneten Mdelle swie deren Elemente. Man kann sich wahlweise alle Elemente eines Mdells der die Elemente der einzelnen Teilmdelle eines Mdells anzeigen lassen. Die Elemente sind unterteilt in Elemente der Fachlichen Ebene, der Lgischen Werkzeugebene und der Physischen Werkzeugebene. Das Dkumentfenster: Im Dkumentfenster werden die grafischen Sichten des Mdells dargestellt. Für jede Gegenstandsebene gibt es jeweils eine sgenannte Einzelebenenansicht, in der eine Auswahl der Knzepte der jeweiligen Gegenstandsebene grafisch visualisiert wird. Es ist ebenfalls möglich, alle drei Ebenen swie die wichtigsten Beziehungen zwischen Elementen unterschiedlicher Ebenen im Dkumentfenster anzuzeigen. Die Menüleiste: Am beren Rand des Fensters befindet sich die Menüleiste, die sämtliche im jeweiligen Kntext sinnvllen Funktinen zur Verfügung stellt. Die Standardsymblleiste: Unter der Menüleiste befindet sich die Standardsymblleiste. Sie enthält einige der am häufigsten verwendeten Funktinen des 3LGM²-Baukastens. Unter anderem kann man über diese Symblleiste für ein Mdell zwischen Einzelebenenansicht und Mehrebenenansicht umschalten. Die Zeichensymblleiste befindet sich am unteren Rand links. Sie enthält die in der ausgewählten Ebene verfügbaren Zeichenbjekte. Da je nach ausgewählter Ebene verschiedene Objekte gezeichnet werden können, unterscheidet sich auch das Aussehen der Zeichensymblleiste je nach gewählter Ebene. Die Ansichtswerkzeuge: Die Ansichtswerkzeuge dienen dazu, die Ansicht des Dkumentfensters je nach Bedarf anzupassen. Ist die Ansicht der Ebenen im Dkumentfenster auf Einzelansicht der Ebenen eingestellt, s kann nur der Zmfaktr verändert werden. Bei Ansicht aller drei Ebenen im Dkumentfenster, können Zmfaktr, Ebenenwinkel und Ebenenabstand verändert werden. 11

14 D Umsetzung des Drei-Ebenen-Metamdells im 3LGM²-Baukasten Abbildung 4: Baukastenübersicht Fast alle in diesem Dkument enthaltenen Abbildungen wurden mit dem 3LGM²-Baukasten in der derzeit verfügbaren Versin 3.2.x erstellt. Eventuelle grafische Abweichungen vn späteren Baukasten-Versinen sind möglich. Mdellelemente, die zum Zeitpunkt der Fertigstellung dieses Reprts nch nicht im 3LGM²-Baukasten verfügbar waren, wurden mit anderen Grafikwerkzeugen beispielhaft dargestellt. Eine detailliertere Beschreibung, insbesndere der verschiedenen Sichten auf ein Infrmatinssystem, die der 3LGM²- Baukastens anbietet, ist in Abschnitt A gegeben. 12

15 E Das Drei-Ebenen-Metamdell 3LGM² zur Beschreibung vn Infrmatinssystemen E Das Drei-Ebenen-Metamdell 3LGM² zur Beschreibung vn Infrmatinssystemen E.A Basis, Erweiterungen und Mdifikatinen des Metamdells Ab der hier dargestellten Versin 3 hat das Drei-Ebenen-Metamdell einen mdularen Aufbau, bestehend aus 3LGM²- B und den Erweiterungen und Mdifikatinen 3LGM²-M und 3LGM²-S. Die Basis für die 3LGM²-Mdellierung und das Verständnis vn 3LGM²-M und 3LGM²-S bildet das 3LGM²-B, welches die wichtigsten Elementklassen für die Mdellierung vn Infrmatinssystemen auf den drei Gegenstandsebenen Fachliche Ebene, Lgische Werkzeugebene und Physische Werkzeugebene enthält. Die Erweiterung 3LGM²-M bezieht sich auf die Lgische Werkzeugebene und erweitert 3LGM²-B um Elementklassen zur Mdellierung der nachrichtenrientierten Kmmunikatin. Während im 3LGM²-B der Austausch vn Daten zwischen verschiedenen Anwendungsbausteinen nur grb beschrieben wird, kann die Kmmunikatin zwischen Anwendungsbausteinen auf der Basis vn Nachrichtentypen und Kmmunikatinsstandards in einem 3LGM²-M- Mdell ausführlich beschrieben werden. Eine Knvertierung eines Mdells vn 3LGM²-M nach 3LGM²-B ist demnach nicht hne Infrmatinsverlust möglich und lässt sich nicht rückgängig machen. Wiederum können nur Mdelle auf der Basis vn 3LGM²-M, d. h. Mdelle in denen bereits Nachrichtentypen mdelliert wurden, autmatisch zu 3LGM²-S Mdellen erweitert werden. 3LGM²-S ist hilfreich für die Mdellierung dienstrientierter (service-rientierter) Kmmunikatin, wie sie zum Beispiel für SOA (Service-Oriented Architectures) relevant ist. Mit 3LGM²-S ist es möglich, ein Infrmatinssystem zu beschreiben, in welchem Anwendungsbausteine spezielle Services anbieten, die vn anderen Anwendungsbausteinen genutzt werden können. Mdelle auf der Basis vn 3LGM²-B können manuell zu 3LGM²-S Mdellen erweitert werden. Eine Rück-Knvertierung vn 3LGM²-S-Mdellen zu 3LGM²-M der 3LGM²-B ist prinzipiell möglich, allerdings nicht verlustls. E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.A Überblick Das Drei-Ebenen-Metamdell 3LGM²-B ist mit den in Abschnitt A erläuterten UML-Knzepten dargestellt. Alle drt verwendeten Klassen bzw. Begriffe werden in den flgenden Abschnitten näher erläutert. Die Zurdnung der Knzepte zu den drei Gegenstandsebenen erflgt anhand derselben Farbcdierung, wie sie in Abbildung 5 zu sehen ist. D. h. die Begriffe der Fachlichen Ebene sind rt, die der Lgischen Werkzeugebene grün und alle Knzepte der Physischen Werkzeugebene sind blau. Grau dargestellte Klassen liegen zwischen 2 Gegenstandsebenen. 13

16 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Abbildung 5: Das Metamdell 3LGM²-B 14

17 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.B Fachliche Ebene Die Fachliche Ebene eines Infrmatinssystems ergibt sich in erster Linie aus den Daten, die im Rahmen der Erledigung vn Aufgaben jeweils erzeugt bzw. benötigt werden. Die Aufgaben sind durch die Organisatin vrgegeben und deren Erledigung muss durch das Infrmatinssystem adäquat unterstützt werden. Die Fachliche Ebene beschreibt damit die fachlichen Knsequenzen aus den Unternehmenszielen und abstrahiert dabei vn den Werkzeugen, die zur Erledigung der Aufgaben eingesetzt werden, und der Frm und dem Ort in bzw. an dem die Daten repräsentiert sind. Anmerkung: Auf der Fachlichen Ebene geht man vn der Vrstellung aus, dass sich die erfrderlichen Daten alle in der betrachteten Welt befinden. Das macht die Vrstellung überflüssig, man müsse auf der Fachlichen Ebene Daten zwischen Aufgaben fließen lassen. Es muss nur dargestellt werden, bei der Erledigung welcher Aufgabe ein Datum erzeugt wird, das bei der Erledigung welcher (anderen) Aufgabe möglicherweise benötigt wird. Abbildung 6: Beispiel der grafischen Sicht einer Fachlichen Ebene. (Rechtecke repräsentieren Aufgaben, Ovale stehen für Objekttypen. Ein Pfeil vn einem Objekttyp zu einer Aufgabe markiert einen interpretierenden Zugriff, ein Pfeil vn einer Aufgabe zu einem Objekttyp einen bearbeitenden Zugriff. Generalisierungen bzw. Aggregatinen sind durch gestrichelte Pfeile dargestellt, die vn dem Unterelement ausgehen und auf das übergerdnete Element hinweisen. Die knkrete Bedeutung wird in E.B.B-1 und E.B.B-2 näher erläutert.) Auf der Fachlichen Ebene kann als beschrieben werden, welche Aufgaben erledigt werden müssen und welche Objekttypen dabei jeweils bearbeitet und interpretiert werden. Smit wird auf dieser Ebene letztlich frmuliert, welche Anfrderungen vn datenverarbeitenden Werkzeugen in einer Organisatin erfüllt werden müssen, damit die Infrmatinsverarbeitung in dieser Organisatin tatsächlich funktiniert. Außerdem lassen sich auf dieser Gegenstandsebene die Unternehmensstruktur über Organisatinseinheiten und deren Beziehung zu den Aufgaben darstellen swie Przessabläufe über Flgen vn Aufgaben beschreiben. 15

18 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.B-1 Objekttyp E.B.B-1.1 Beschreibung des Knzepts 2 Ein Infrmatinssystem verarbeitet Daten. Die Daten repräsentieren Infrmatinen über physische der virtuelle Objekte (engl. bjects, vgl. part f the perceivable r cnceivable universe [14]). Gleichartige Dinge werden in Objektklassen 3 zusammengefasst. In einem Krankenhaus gibt es zum Beispiel flgende Objektklassen: Patient, Pflegekraft, Ärztin/Arzt, Befund, durchgeführte Operatin. Definitin: Objekttyp Ein Objekttyp (engl. entity type ) repräsentiert 1. eine Objektklasse und zeigt an, dass die repräsentierte Klasse vn Objekten für das Infrmatinssystem interessant ist und drt grundsätzlich Daten 4, die Infrmatinen über Objekte dieser Klasse repräsentieren, gespeichert werden können swie 2. die Daten, die Infrmatinen über Objekte dieser Objektklasse repräsentieren, und in dem Infrmatinssystem gespeichert werden bzw. gespeichert werden können der sllen.. Bei der Mdellierung erhält ein Objekttyp als Bezeichnung die Bezeichnung der Objektklasse, auf die er verweist. Zur Vereinfachung sagen wir Daten eines Objekttyps wenn wir die vn dem Objekttyp repräsentierten Daten meinen. Zum Beispiel repräsentiert der Objekttyp Befund (siehe Abbildung 6) swhl 1. die Klasse aller Befunde eines Krankenhauses und zeigt an, dass Befunde für das Infrmatinssystem des Krankenhauses interessant sind und drt grundsätzlich Befunddaten gespeichert werden können swie 2. die Befunddaten, die in diesem Infrmatinssystem gespeichert werden bzw. gespeichert werden können der sllen. Weitere für Krankenhäuser typische Objekttypen werden in [15] beschrieben. Abbildung 7: Beispiel eines Objekttyps 2 Vgl. ([13], S. 67, 70) 3 vgl. cncept als unit f thught cnstituted thrugh abstractin n the basis f prperties cmmn t a set f bjects [14]). 4 In ([13], S. 67f) werden Daten als Explikatinen sgenannter Infrmatinsbjekte bezeichnet. Ein Infrmatinsbjekt ist drt eine abstrakte, aussagekräftige Repräsentatin vn Feststellungen über ein einzelnes, knkrete, benennbares Objekt. Wir verzichten hier auf den Begriff des Infrmatinsbjekts und sprechen unmittelbar vn Daten als Beschreibungen vn Objekten. 16

19 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.B-1.2 Spezielle Frmen vn Objekttypen Eine spezielle Frm vn Objekttypen sind Begriffssysteme. Siehe E.B.B-3. E.B.B-1.3 Spezialisierung und Zerlegung vn Objekttypen E.B.B Knzept Objekttypen können swhl durch Spezialisierung als auch durch Zerlegung in Unterbjekttypen gegliedert werden. Bei einer Spezialisierung kann ein Gruppenbjekttyp (leicht) unterschiedliche Ausprägungen haben, die ihm in Frm seiner Unterbjekttypen untergerdnet werden. Die Unterbjekttypen werden über das UML-Knzept der Aggregatin dem Gruppenbjekttyp untergerdnet. Jeder Objekttyp kann über diese Beziehung genau einem anderen Objekttyp untergerdnet sein. Bei einer Zerlegung versteht man die Unterbjekttypen als echten Teil des Gruppenbjekttyps. Sie werden über das UML-Knzept der Kmpsitin dem Gruppenbjekttyp untergerdnet. Jeder Objekttyp kann über diese Beziehung beliebig vielen anderen Objekttypen untergerdnet sein. Abbildung 6 zeigt Beispiele für Spezialisierung und Zerlegungen vn Objekttypen: In Abbildung 6 ist der Objekttyp ADT Infrmatin mit den Unterbjekttypen Patientenstamminfrmatin und Fall Beispiel für eine Zerlegung, whingegen Befund durch Befundbericht Radilgie und Befundbericht Labr spezialisiert wird. E.B.B Vererbung Eine Vererbung drückt aus, dass bei Spezialisierung und Zerlegung alle Eigenschaften des Gruppenbjekttyps auch für die Unterbjekttypen als gegeben angesehen werden sllen, die Bestandteile dieses Gruppenbjekttyps sind, d. h. Eigenschaften und Assziatinen werden an die Unterbjekttypen vererbt. Dies bedeutet, dass alle Beziehungen zu Aufgaben, Anwendungsbausteinen, Begriffssystemen, Sendeschnittstellen, Empfangsschnittstellen und zu Kmmunikatinsverbindungen, die für den Gruppenbjekttyp mdelliert sind, auch als für alle seine Unterbjekttypen mdelliert gelten, als vererbt werden. Entsprechend ist in Abbildung 6 aus der Tatsache, dass die Aufgabe Diagnstische und therapeutische Maßnahmendurchführung eine Beziehung zum Objekttyp ADT Infrmatinen hat, abzuleiten, dass dessen Unterbjekttypen Patientenstamminfrmatin und Fall ebenfalls diese Beziehung zu der Aufgabe besitzen. Die verschiedenen Ausprägungen des spezialisierten Objekttyps Befund müssen jedch nicht gemeinsame Beziehungen zu Aufgaben haben. Smit ist es häufig nur bei Objekttypen mit Kmpsitinsbeziehung sinnvll, dem Gruppenbjekttyp Beziehungen zu anderen Elementklassen zuzurdnen. E.B.B Vergröbern Bei dem Vergröbern eines Gruppenbjekttyps werden seine Unterbjekttypen (vrübergehend) aus dem Mdell entfernt. Dies bedeutet, dass auf die differenzierte Betrachtung, die durch die Unterbjekttypen gegeben ist, verzichtet wird. Die Assziatinen der Unterbjekttypen zu Aufgaben, Anwendungsbausteinen, Sendeschnittstellen, Empfangsschnittstellen und zu Kmmunikatinsverbindungen werden dann für die Dauer der Vergröberung vllständig dem Gruppenbjekttyp zugerdnet. E.B.B-1.4 Beziehungen wird interpretiert und wird bearbeitet zu Aufgabe Objekttypen können vn Aufgaben interpretiert und bearbeitet werden. Dies wird in E.B.B-2.1 und E.B.B-2.3 näher erläutert. Zur Kardinalität der Beziehung siehe auch E.B.B-2.7. Im Beispiel in Abbildung 6 wird die interpretierende Beziehung durch einen Pfeil vm Objekttyp zur Aufgabe und die bearbeitende Beziehung durch einen Pfeil vn der Aufgabe zum Objekttyp dargestellt. E.B.B-1.5 Interebenenbeziehung wird gespeichert vn zu Anwendungsbaustein Die Daten über Objekte, auf die ein bestimmter Objekttyp verweist, werden durch Anwendungsbausteine gespeichert. Nur in Anwendungsbausteinen, die für diesen Objekttyp als Master gekennzeichnet werden, dürfen diese Daten erzeugt der geändert werden; in anderen Anwendungsbausteinen, die Daten über diese Objekte speichern, dürfen diese Daten nur gelesen werden. 17

20 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.B-1.6 Interebenenbeziehung wird gesendet vn zu Sendeschnittstelle, wird empfangen vn zu Empfangsschnittstelle und wird übertragen vn zu Kmmunikatinsverbindung Werden die Daten über Objekte, auf die ein bestimmter Objekttyp verweist, in mehreren Anwendungsbausteinen gespeichert, dann müssen diese Daten zwischen diesen Anwendungsbausteinen auch ausgetauscht, d. h. kmmuniziert werden. Darüber hinaus werden die Daten ggf. auch in Anwendungsbausteinen benötigt, in denen sie nicht gespeichert werden. Dies kann zum Beispiel dann der Fall sein, wenn ein slcher Anwendungsbaustein eine Aufgabe unterstützt, die den auf die Daten verweisenden Objekttyp interpretiert. Zwischen den Anwendungsbausteinen werden die Daten, auf die ein bestimmter Objekttyp verweist, kmmuniziert. Die Assziatin eines Objekttyps zu einer Sendeschnittstelle beschreibt, dass diese Sendeschnittstelle Daten versenden kann, die Infrmatinen über Objekte repräsentieren, welche durch den Objekttyp beschrieben sind. Vereinfachend kann davn gesprchen werden, dass die Sendeschnittstelle den Objekttyp versenden kann. Die Assziatin eines Objekttyps zu einer Empfangsschnittstelle beschreibt, dass diese Empfangsschnittstelle Daten empfangen kann, die Infrmatinen über Objekte repräsentieren, welche durch den Objekttyp beschrieben sind. Vereinfachend kann davn gesprchen werden, dass die Empfangsschnittstelle den Objekttyp empfangen kann. Die Assziatin eines Objekttyps zu einer Kmmunikatinsverbindung beschreibt, dass diese Kmmunikatinsverbindung Daten transprtiert, die Infrmatinen über Objekte repräsentieren, welche durch den Objekttyp beschrieben sind. Vereinfachend kann davn gesprchen werden, dass die Kmmunikatinsverbindung den Objekttyp transprtiert. E.B.B-1.7 Fragen des Infrmatinsmanagements und Unterstützung durch den 3LGM²-Baukasten Besnders interessante Fragen in Bezug auf Objekttypen, die für das Management vn Infrmatinssystemen relevant sind, sind in der flgenden Tabelle zusammen mit den Hinweisen auf die Stellen, w diese Fragen näher behandelt werden, aufgeführt. Fragen des Infrmatinsmanagements Welche Aufgaben sind auf Daten eines bestimmten Objekttyps angewiesen? Bei der Erledigung welcher Aufgaben werden die Daten eines bestimmten Objekttyps erzeugt? Verweis auf Text E.B.B-2.3 E.B.B-2.3 W werden die Daten eines bestimmten Objekttyps gespeichert? E.B.B-1.5, E.B.D- 1.8 Zwischen welchen Anwendungsbausteinen werden die Daten eines bestimmten Objekttyps kmmuniziert? Gibt es ausreichende Kmmunikatinsmöglichkeiten, um die Daten eines bestimmten Objekttyps zwischen den Anwendungsbausteinen zu kmmunizieren, in denen sie gespeichert werden? E.B.B-1.6, E.B.D-3 E.B.B-1.6, E.B.D-3 Welche Datendmäne hat ein Objekttyp, d. h. welche Anwendungsbausteine benötigen den Objekttyp? [16] Gibt es ausreichende Kmmunikatinsmöglichkeiten, um die Daten eines bestimmten Objekttyps vn den Anwendungsbausteinen, in denen sie gespeichert werden, zu den Anwendungsbausteinen zu kmmunizieren, in denen sie zur Erledigung vn Aufgaben benötigt werden? [17] E.B.B-1.8 Mdellierungshinweise Bei der Bezeichnung eines Objekttyps ist darauf zu achten, dass diese Bezeichnung auch für die Instanzen der Objektklasse verwendet werden kann, auf die der Objekttyp verweist. Insbesndere sllte daher die jeweilige Singularfrm gewählt werden. S sllte ein Objekttyp, der auf die Objektklasse der Patienten eines Krankenhauses verweist, mit Patient und nicht mit Patienten bezeichnet werden. In Anwendung dieses Prinzips sllte auch ein Objekttyp, der auf den ICD-10 Katalg der Diagnsenklassen verweist, d. h. ein Begriffssystem (siehe E.B.B-3), z. B. als ICD-10-Diagnseklasse bezeichnet werden. Bei einem Objekttyp ICD-10-Katalg würde dagegen davn ausgegangen werden, dass jede Instanz ein ICD-10 Katalg ist und mit diesem Objekttyp eine Menge vn ICD-Katalgen, z. B. unterschiedlicher Versinen, gemeint ist. Bei der Mdellierung eines Objekttyps sllte immer beschrieben werden, was genau die Objektklasse ist, auf die er verweist und mit welchen Merkmalsarten die Objekte beschrieben werden. Ferner ist es hilfreich, sich 18

21 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B stets zu vergegenwärtigen, dass ein Objekttyp stets Daten über die bzw. zur Beschreibung der Objekte der Objektklasse meint; nie jedch die Objekte selbst. Jeder Objekttyp sllte vn mindestens einer Aufgabe interpretiert werden. Ein Objekttyp, der vn keiner Aufgabe interpretiert wird, ist in einem Mdell möglicherweise überflüssig. Das Vererbungsprinzip ist stets srgfältig zu beachten. S ist stets zu beachten, dass z. B. eine Beziehung die ein Gruppenbjekttyp mit einer Aufgabe hat, auch für alle Unterbjekttypen gegeben ist. Dies gilt auch dann, wenn einem Gruppenbjekttyp erst später Unterbjekttypen zugerdnet werden, als der Objekttyp zum Gruppenbjekttyp wird. Es wird nicht immer davn auszugehen sein, dass alle Eigenschaften des Gruppenbjekttyps auch für alle Unterbjekttypen gelten. Es sllte als immer überprüft werden, b wirklich nur die Eigenschaften bei dem neuen Gruppenbjekttyp belassen wrden sind, die auch wirklich für alle Unterbjekttypen gelten sllen. Diese Situatin ergibt sich z. B., wenn Objekttypen eines Referenzmdells in ein Mdell übernmmen, drt aber zur präziseren Mdellierung aufgeteilt werden. Grundsätzlich sllte als vermieden werden, Gruppenbjekttypen Beziehungen zuzuweisen. Zur Unterstützung der Mdellierung bietet der 3LGM²-Baukasten eine Funktin, mit der alle der eine Auswahl der vererbbaren Eigenschaften und Beziehungen eines Gruppenbjekttyps explizit auf alle Unterbjekttypen übertragen und bei dem Gruppenbjekttyp entfernt werden. Ein Gruppenbjekttyp sllte mindestens zwei Unterbjekttypen haben. Vn dieser Regel kann z. B. abgewichen werden, wenn es sich bei dem Gruppenbjekttyp um einen Elementarbjekttyp, d. h. um einen Objekttypen hne weitere Unterelemente, aus einem Referenzmdell handelt, aber in dem Mdell eine detailliertere Aussage nötig erscheint. In diesem Fall sind wiederum die Hinweise zur Vererbung zu beachten. Es sllten flgende Mdellierungsregeln für Objekttypen beachtet werden, insbesndere bei Verwendung des Phasenmdells für die Mdellierung vn Aufgaben und Objekttypen (vgl. E.B.B-2.7). Jeder Objekttyp muss genau eine Klasse darstellen. Eine Klasse darf nicht vn mehr als einem Objekttyp dargestellt werden. Die Bezeichnung eines Objekttyps sllte aus einem dmänenspezifischen, standardisierten Vkabular (z. B. einem Glssar, einem Fachwörterbuch, einem Standard der einer Nmenklatur) entnmmen sein. Die Bezeichnung eines Objekttyps muss ein Substantiv enthalten, das als Bezeichnung für jedes einzelne der Objekte der vm Objekttyp dargestellten Klasse geeignet ist. Die Bezeichnung eines Objekttyps darf nicht geeignet sein, andere Objekte als die Objekte der vm Objekttyp dargestellten Klasse zu bezeichnen. Die Bezeichnung muss s kurz wie möglich gewählt sein. Zu jedem Objekttyp sllte die Definitin der vn diesem Objekttyp dargestellten Klasse dkumentiert sein. Die Definitin zu einem Objekttyp sllte nicht frei erstellt, sndern unter Angabe der Quelle einem zitierfähigen Dkument entnmmen sein. Für jeden Objekttyp muss ein Identitätsprinzip angegeben werden. Für Objekttypen, die keine ein Identitätsprinzip spendende Klasse darstellen, kann das Identitätsprinzip angegeben werden, indem die Klasse angegeben wird, vn dem die vm Objekttyp dargestellte Klasse ihr Identitätsprinzip bezieht. Für nähere Erläuterungen der Mdellierungsregeln siehe [13]. E.B.B-2 Aufgabe E.B.B-2.1 Beschreibung des Knzepts Aktivitäten im Rahmen der datenverarbeitenden Przesse eines Infrmatinssystems verändern der löschen bestimmte Daten und sind dabei auf bestimmte schn vrhandene Daten angewiesen. Mit einem Objekttyp können wir alle Daten über Objekte einer bestimmten Klasse repräsentieren (siehe Definitin in E.B.B-1.1). Das wiederum ermöglicht es, auch gleichartige Aktivitäten zusammenzufassen: 19

22 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Wir können slche Aktivitäten als gleichartig zusammenzufassen, welche die Daten derselben Objekttypen verändern der löschen, und gleichzeitig dabei auf die Daten derselben Objekttypen angewiesen sind. Eine s definierte Klasse gleichartiger Aktivitäten bezeichnen wir als datenverarbeitende Aufgabe. Eine datenverarbeitende Aufgabe wird flglich durch die Objekttypen gekennzeichnet, deren Daten ihre Aktivitäten verarbeiten bzw. auf die sie angewiesen sind. In der wirtschaftswissenschaftlichen Literatur ist eine Unternehmensaufgabe [18] (engl. "enterprise functin" [19]) nach [20], S. 147, eine Zielvrschrift für menschliches der maschinelles Handeln. Das durch das Handeln zu erreichende Ziel deckt sich mit einem der unterstützt die Erreichung eines (Teil-) Ziels einer Organisatin. Vr diesem Hintergrund sind datenverarbeitende Aufgaben stets Teilaufgaben einer Unternehmensaufgabe. Die erwähnte Zielvrschrift ist für datenverarbeitende Aufgaben als eine Vrschrift zu verstehen, wie Daten bestimmter Objekttypen verändert der gelöscht werden sllen. Definitin: Aufgabe Eine datenverarbeitende Aufgabe (kurz: Aufgabe) ist eine Zielvrschrift, wie auf Grund vn Daten bestimmter Objekttypen Daten anderer Objekttypen verändert der gelöscht werden sllen. Das durch die Veränderung der Löschung zu erreichende Ziel deckt sich mit einem der unterstützt die Erreichung eines (Teil-) Ziels einer Organisatin. Eine Aufgabe hat keinen definierten Anfang und kein definiertes Ende. Man kann eine Aufgabe als Pflicht auffassen (siehe ben Zielvrschrift ), die sich aus den Zielen des Unternehmens mehr der weniger zwingend ergibt. Die Zielvrschrift wird durch knkretes Handeln erfüllt. Das knkrete Handeln einer menschlichen Persn der einer Maschine in einem bestimmten Zeitraum zur einmaligen Erledigung einer Aufgabe ist eine Aktivität; eine Aktivität kann als Instanz einer Aufgabe aufgefasst werden. Aktivitäten finden nicht nur wie eingangs erläutert, im Rahmen eines Przesses statt, sndern durchlaufen bei Ihrer Erledigung selber wieder Przesse. Daher kann eine Aufgabe auch als Repräsentant der Przesse aufgefasst werden, die bei der Erledigung seiner Aktivitäten durchlaufen werden. Als Bezeichnungen für Aufgaben werden Substantive bzw. substantivierte Verben gewählt. Typische, in einem Krankenhaus zu erledigende Aufgaben sind z. B. Patientenaufnahme, Termin- und Ressurcenplanung, diagnstische und therapeutische Maßnahmendurchführung. Weitere für Krankenhäuser typische Aufgaben werden in [15] beschrieben. E.B.B-2.2 Spezialisierung und Zerlegung vn Aufgaben E.B.B Knzept Analg zu Objekttypen wird bei Aufgaben ebenfalls zwischen Spezialisierung und Zerlegung unterschieden: Spezialisierung bedeutet, dass die Unteraufgabe eine spezielle Art der Gruppenaufgabe darstellt bzw. die Gruppenaufgabe eine Generalisierung der Unteraufgabe ist. Inhaltlich bedeutet dies, dass eine Aufgabe in bestimmten Kntexten in (leicht) unterschiedlicher Frm erledigt wird. Diese unterschiedlichen Frmen der Erledigung werden durch ihre Unteraufgaben ausgedrückt. Bei einer Zerlegung hingegen ist die Unteraufgabe als echter Teil der Gruppenaufgabe zu verstehen, d. h. erst wenn alle Unteraufgaben erledigt sind, dann ist auch die Gruppenaufgabe vllständig erledigt. In einem slchen Fall kann davn ausgegangen werden, dass ein Przess existiert, der beschreibt, in welcher Reihenflge bzw. unter welchen Bedingungen welche der Unteraufgaben erledigt werden sllen (allerdings wird der Przess hier nicht mdelliert). Das heißt die Unteraufgaben müssten immer gemeinsam bzw. in einer bestimmten Abflge erledigt werden und nicht, wie bei einer Spezialisierung alternativ. Abbildung 6 zeigt Beispiele für Spezialisierung und Zerlegung bei Aufgaben: Die Aufgabe Diagnstische und therapeutische Maßnahmendurchführung hat die Unteraufgaben Radilgische Diagnstik, Labrdiagnstik und Raditherapie (dargestellt durch unterbrchene Pfeile, die vn den Unteraufgaben auf die Gruppenaufgabe zeigen). Es handelt sich bei der Radilgischen Diagnstik, der Labrdiagnstik und der Raditherapie um Spezialisierungen der diagnstischen und therapeutischen Maßnahmendurchführung, d. h. sie können alternativ durchgeführt werden. Die Gruppenaufgabe Radilgische Diagnstik wurde zerlegt in zwei Unteraufgaben (Zerlegung). D. h. swhl die Radilgische Bilderzeugung als auch die Radilgische Bildbefundung müssen innerhalb der Radilgischen Diagnstik erflgen. 20

23 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.B Vererbung Bei Spezialisierung und Zerlegung werden alle Eigenschaften und Assziatinen, die der Gruppenaufgabe zugewiesen werden, auch für ihre Unteraufgaben als gegeben angesehen, d. h. die Eigenschaften werden vererbt. Dies bedeutet, dass alle Beziehungen zu Objekttypen, Przessen und Anwendungsbausteinen, die für eine Gruppenaufgabe mdelliert sind, auch als für alle ihre Unteraufgaben mdelliert gelten. Der Pfeil des blauen Ovals ADT Infrmatin auf die übergerdnete Aufgabe in Abbildung 6 stellt dar, dass diese Aufgabe einen entsprechenden Objekttyp interpretiert. Für alle Unteraufgaben gilt demnach auch, dass sie ADT Infrmatin interpretieren. E.B.B Vergröbern Bei dem Vergröbern einer Gruppenaufgabe werden die Unteraufgaben (vrübergehend) aus dem Mdell entfernt (vgl. C.D). Dies bedeutet, dass dann auf die differenzierte Betrachtung, die durch die Unteraufgaben gegeben ist, verzichtet wird. Die Assziatinen der Unteraufgaben werden dann für die Dauer der Vergröberung wie flgt der übergerdneten Aufgabe zugerdnet: Objekttypen: Alle interpretierenden/bearbeitenden Assziatinen der Unteraufgaben zu Objekttypen (siehe E.B.B-2.3, E.B.B-1) werden der vergröberten Aufgabe zugerdnet. Nutzung: Alle Assziatinen der Unteraufgaben zu Nutzungen (siehe auch E.B.B-4), werden der vergröberten Aufgabe zugerdnet. Das bedeutet, dass aufgrund der gewllten Vergröberung und des Verzichts auf Differenzierung, die den jeweiligen Unteraufgaben zugerdneten Anwendungsbausteine als gleichwertig und damit alternativ zur Erledigung der Gruppenaufgabe der zur Vermittlung vn Anwendungsbausteinen zur Erledigung der Aufgabe (siehe E.B.B-4) einsetzbar angesehen werden. Przess: Das Zugehörigkeit einer Unteraufgabe zu einem Przess wird ebenfalls beim Vergröbern an ihre übergerdneten Aufgaben übertragen (siehe E.B.B-6). Es bleibt zu beachten, dass ein und dieselbe Unteraufgabe gleichzeitig mehreren anderen Aufgaben untergerdnet sein kann. Slange nicht alle Aufgaben eines Mdells, denen dieselbe Unteraufgabe zugerdnet ist auch gleichzeitig vergröbert sind, wird diese Unteraufgabe nicht inhaltlich ausgeblendet. E.B.B-2.3 Beziehungen interpretiert und bearbeitet zu Objekttyp Eine Aufgabe ist eine Zielvrschrift, wie auf Grund vn Daten bestimmter Objekttypen Daten anderer Objekttypen verändert der gelöscht werden sllen. Die Objekttypen, deren Daten als Grundlage der Veränderung der Löschung erfrderlich sind, werden als interpretierte Objekttypen bezeichnet. Die Objekttypen, deren Daten verändert der gelöscht werden sllen, werden als bearbeitete Objekttypen bezeichnet. Wenn eine Aufgabe mehrere Objekttypen interpretiert, bedeutet dies, dass bei der Erledigung der Aufgabe Daten aller interpretierten Objekttypen erfrderlich sind. (siehe auch die Mdellierungshinweise in E.B.B-2.7) Wenn eine Aufgabe mehrere Objekttypen bearbeitet, bedeutet dies, dass bei der Erledigung der Aufgaben Daten aller bearbeiteten Objekttypen erzeugt bzw. verändert werden. Da dies zu Interpretatinsschwierigkeiten führen kann, wird empfhlen, jeweils nur einen Objekttypen als bearbeitet zu mdellieren (siehe auch die Mdellierungshinweise in E.B.B-2.7). Ggf. ist dazu in Betracht zu ziehen, die Aufgabe zu zerlegen der zu spezialisieren (siehe E.B.B-2.2.1). In der grafischen Sicht der Fachlichen Ebene werden die vn einer Aufgabe interpretierten Objekttypen im Baukasten durch einen Pfeil vn dem Objekttyp zur Aufgabe kenntlich gemacht. Der vn einer Aufgabe bearbeitete Objekttyp wird im Baukasten graphisch durch einen Pfeil vn der Aufgabe zum Objekttyp dargestellt. In Abbildung 6 bearbeitet die Aufgabe Erstellung eines Auftrags für ein Maßnahme den Objekttyp Anfrderung Radilgie. Dies bedeutet, dass bei der Erledigung der Auftragserstellung Daten entstehen, die Infrmatinen über Anfrderungen an die Radilgie repräsentieren. Die Aufgabe Radilgische Diagnstik interpretiert wiederum den Objekttyp Anfrderung Radilgie. Dies bedeutet, dass bei der Erledigung dieser Aufgabe Daten, die Infrmatinen über Anfrderungen für die Radilgie repräsentieren, in andere Daten transfrmiert werden. Kurz gesagt wird als bei der Erstellung eines Auftrags für eine Maßnahme eine Anfrderung erstellt, die dann bei der Radilgischen Diagnstik erfüllt wird. E.B.B-2.4 Beziehung wird erledigt über zu Nutzung Durch die Beziehung zur Klasse Nutzung wird ausgedrückt, dass zur Erledigung einer bestimmten Aufgabe in bestimmten Organisatinseinheiten jeweils bestimmte Anwendungsbausteine genutzt werden (der kurz: die Aufgabe 21

24 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B wird durch Nutzung eines Anwendungsbausteins erledigt). Die Assziatin zwischen Nutzung und Anwendungsbausteinen ist über die Assziatinsklasse Unterstützung näher bestimmt, wdurch zusätzlich ausgedrückt werden kann, dass die Funktinalität eines Anwendungssystem, das für die Erledigung einer Aufgabe genutzt wird, durch ein anderes Anwendungssystem vermittelt wird (vgl. E.B.B-4). Kann eine Aufgabe innerhalb einer Organisatinseinheit der auch in verschiedenen Organisatinseinheiten durch mehrere Anwendungsbausteine unterstützt (der zusätzlich auch vermittelt) werden, dann wird davn ausgegangen, dass jeder dieser Anwendungsbausteine die Erledigung der Aufgabe in gleicher Weise und Qualität unterstützt (bzw. einen Anwendungsbaustein zur Erledigung vermittelt); flglich könnten alle unterstützenden Anwendungsbausteine gegeneinander und alle vermittelnden Anwendungsbausteine auch jeweils untereinander hne Verlust an Funktinalität wechselseitig ausgetauscht werden. E.B.B Kmpatibilität zu 3LGM² V1.x Diese Beziehung ersetzt die Anwendungsbausteinknfiguratin. E.B.B-2.5 Interebenenbeziehung kann unterstützt werden durch zu Sftwareprdukt Die zuvr genannte Beziehung zu Nutzung drückt aus, dass zur Erledigung einer bestimmten Aufgabe tatsächlich in einer bestimmten Organisatinseinheit bestimmte Anwendungsbausteine durch Mitarbeiter der Organisatin genutzt werden können. Demgegenüber drückt die Beziehung zu Sftwareprdukt aus, dass die zu der Aufgabe in Beziehung stehenden Sftwareprdukte zur Realisierung vn Anwendungssystemen genutzt werden könnten, mit denen die Aufgabe dann unterstützt werden kann. E.B.B-2.6 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Verweis auf Text Welche Daten werden für die Erledigung der Aufgaben benötigt und welche Daten entstehen dabei? E.B.B-1.4, E.B.B- 2.3 Welche datenverarbeitenden Werkzeuge werden in der Organisatin eingesetzt, um die Erledigung der Aufgaben zu unterstützen? Welche funktinale Dmäne hat eine Aufgabe, d. h. welche Anwendungsbausteine werden benötigt, um die Aufgabe zu erledigen? Für die Erledigung welcher Aufgaben werden in der Organisatin mderne rechnerbasierte Werkzeuge genutzt? Für welche Aufgaben nicht? Ist das Infrmatinssystem vertikal fragmentiert? Werden für die Erledigung derselben Aufgabe in unterschiedlichen Verantwrtungsbereichen der Organisatin unterschiedliche Werkzeuge eingesetzt? (Vertikale Fragmentierung eines Infrmatinssystems liegt laut [16, 21] vr, wenn verschiedene Persnen in verschiedenen Organisatinseinheiten verschiedene Anwendungssysteme benutzen, um verschiedene der auch gleiche Unternehmensaufgaben zu erledigen. Das bedeutet, jede Organisatinseinheit hat ihre eigene Business-Architektur, Anwendungsarchitektur und Technlgie-Architektur.) Warum unterscheiden wir eigentlich die verschiedenen speziellen Frmen einer bestimmten Aufgabe (z. B. der Leistungsanfrderung)? Das ist dch eigentlich immer dasselbe (z. B. Anfrderung eines Labrbefundes der eines pathlgischen Befundes). Was wäre, wenn wir das nicht mehr unterscheiden würden; auf wie viele und welche speziellen Anwendungssysteme könnten wir dann eigentlich verzichten? Wird eine bestimmte Aufgabe ft im Kntext anderer Aufgaben erledigt? Wenn ja, sllten die unterstützenden Anwendungssysteme möglicherweise besnders eng miteinander integriert sein? Wenn eine Aufgabe erledigt werden sll, werden dafür bestimmte Eingabedaten benötigt, die wiederum Ausgabedaten anderer Aufgaben sind. Welche anderen Aufgaben müssen als erledigt werden, damit die betrachtete Aufgabe auch erledigt werden kann? Kann die Erledigung einer bestimmten Aufgabe auch durch andere Sftwareprdukte unterstützt werden, als die, die bereits im Infrmatinssystem der Organisatin im Einsatz sind? E.B.C, [16] E.B.C, E.B.D-1 E.B.D-1, E.B.C E.B.B-2.2.3, [22] E.B.B E.B.B-2.3 E.B.B

25 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.B-2.7 Mdellierungshinweise Aufgaben bearbeiten in der Regel (mindestens) einen Objekttyp. Wenn ein Mensch eine Aufgabe erledigt, und dabei Infrmatinen verwendet, die nicht außerhalb seiner Persn im Infrmatinssystem durch Daten repräsentiert sind, werden diese Infrmatinen in der Regel nicht durch einen Objekttyp mdelliert. Auf diese Weise kann es als dazu kmmen, dass es in einem Mdell Aufgaben gibt, die keinen Objekttyp interpretieren. Es kann auch sinnvll sein, Aufgaben zu mdellieren, bei denen es auf den Aspekt der Datenverarbeitung zunächst nicht ankmmt. Slche Aufgaben werden auch als Unternehmensaufgaben bezeichnet. Slche Unternehmensaufgaben sind z. B. Therapie, Strategischen Rahmenplan erstellen etc. Möglicherweise wird man darauf verzichten, eine Beziehung vn slchen Aufgaben zu Objekttypen zu mdellieren. Da es im Kntext vn 3LGM² aber um die Mdellierung vn Infrmatinssystemen geht, sllten in slchen Fällen datenverarbeitende Teilaufgaben der Unternehmensaufgaben definiert werden, die mit Objekttypen in interpretierender und bearbeitender Beziehung stehen. Das Vererbungsprinzip ist stets srgfältig zu beachten. S ist stets zu beachten, dass z. B. eine Beziehung, die eine Aufgabe mit einem Objekttyp hat, auch für alle ihre Unteraufgaben gegeben ist. Dies gilt auch dann, wenn einer Aufgabe erst später Unteraufgaben zugerdnet werden. Weder bei aggregierenden nch generalisierenden Aufgaben wird jedch immer davn auszugehen sein, dass alle Eigenschaften einer Aufgabe auch für alle ihre Unteraufgaben gelten. Es sllte als immer überprüft werden, b wirklich nur die Eigenschaften bei einer Aufgabe belassen wrden sind, die auch wirklich für alle ihre Unteraufgaben gelten sllen. Diese Situatin ergibt sich z. B., wenn Aufgaben eines Referenzmdells in ein Mdell übernmmen, drt aber zur präziseren Mdellierung weiter zerlegt der spezialisiert werden. Grundsätzlich sllten Beziehungen zu anderen Elementen möglichst immer für Elementaraufgaben als Aufgaben hne eigene Unteraufgaben mdelliert werden. Eine Aufgabe sllte bei Zerlegung in mindestens zwei Unteraufgaben zerlegt werden. Vn dieser Regel kann z. B. abgewichen werden, wenn es sich bei der Gruppenaufgabe um eine Elementaraufgabe aus einem Referenzmdell handelt, aber in dem Mdell eine detailliertere Aussage nötig erscheint. Ebens kann eine Unternehmensaufgabe, die nicht direkt Objekttypen bearbeitet der interpretiert, aus genau einer datenverarbeitenden Aufgabe bestehen, welche direkt mit Objekttypen assziiert ist. In slch einem Fall sind wiederum die Hinweise zur Vererbung zu beachten. Eine Aufgabe muss entweder Elementaraufgabe, aggregierende Aufgabe der generalisierende Aufgabe sein. Die Knzepte der aggregierenden und generalisierenden Aufgaben dürfen nicht vermengt werden. Es gibt insbesndere zwei Wege, Aufgaben zu mdellieren: Man durchläuft flgende Phasen bei der Mdellierung der Fachlichen Ebene: 1. Zunächst werden die Objekttypen identifiziert, die für das Anwendungsgebiet relevant sind. 2. Ausgehend vn den Objekttypen werden Aufgaben mdelliert, die die Objekttypen bearbeiten. Dabei handelt es sich um Aufgaben, die Daten über die Objekttypen erfassen, verändern der vernichten. 3. Es werden Objekttypen mdelliert, die vn den zuvr identifizierten Aufgaben interpretiert werden. 4. Schließlich werden die im zweiten Schritt identifizierten datenverarbeitenden Aufgaben Unternehmensaufgaben zugerdnet. Die Unternehmensaufgaben werden dazu als übergerdnete Aufgaben eingeführt. Bei der Anwendung des Phasenmdells sllen flgenden Mdellierungsregeln für Aufgaben beachtet werden: Eine Aufgabe muss genau einen Objekttyp bearbeiten. Eine Aufgabe muss mit dem bearbeiteten Objekttyp und der Operatin bezeichnet sein, als dem Schema Infrmatinen über... erfassen/verändern/vernichten entsprechen. Eine Aufgabe darf nicht die gleiche Bezeichnung wie eine andere Aufgabe tragen. Jeder Objekttyp muss vn einer Aufgabe bearbeitet werden, die seine Infrmatinsbjekte erzeugt, als mit der Operatin erfassen gekennzeichnet ist. 23

26 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Eine Unternehmensaufgabe darf keinen Objekttyp bearbeiten. Eine Unternehmensaufgabe kann Objekttypen interpretieren. Eine Aufgabe darf nicht einer anderen Aufgabe übergerdnet sein. Eine Unternehmensaufgabe kann übergerdnetes Element einer Unterrdnungsbeziehung sein (Zerlegung der Spezialisierung). Ausführliche Beschreibungen der Mdellierungsregeln und des Phasenmdells swie dabei zu verwendende Entwurfsmustern findet man in [13]. Die Fachlichen Ebenen vn Mdellen ihrer Infrmatinssysteme sind in Organisatinen derselben Branche meist gleich der zumindest sehr ähnlich. Für Krankenhäuser wurde daher in [15] ein Referenzmdell vrgestellt, das die für Krankenhäuser typischen Aufgaben und Objekttypen swie ihre Beziehungen darstellt. Abbildung 6 enthält einige Aufgaben und Objekttypen dieses Referenzmdells (z. B Erstellung eines Auftrags für eine Maßnahme, Diagnstische und Therapeutische Maßnahmendurchführung; ADT Infrmatin). Es bietet sich an, bei der Mdellierung eines bestimmten Infrmatinssystems Aufgaben aus z. B. diesem Referenzmdell auszuwählen; ggf. kann die Mdellierung durch Spezialisierung der Zerlegung der Elementaraufgaben des Referenzmdells präzisiert werden. In Abbildung 6 werden z. B. Spezialisierungen für die Aufgabe Diagnstische und Therapeutische Maßnahmendurchführung angegeben, die im Referenzmdell der Fachlichen Ebene nicht enthalten sind. E.B.B-3 Begriffssystem E.B.B-3.1 Beschreibung des Knzepts Eine besndere Frm vn Objekttypen sind Begriffssysteme. Nach [23] ist ein Begriffssystem eine Menge vn Begriffen, die je nach Begriffssystem mehr der weniger gerdnet sind. Gelegentlich werden Begriffssysteme als Ontlgien bezeichnet. Beispielsweise ist die internatinale Klassifikatin der Krankheiten in der zehnten Revisin, d. h. die ICD- 10 ein slches Begriffssystem. E.B.B-3.2 Spezialisierung und Zerlegung vn Begriffssystemen Es gelten die gleichen Regeln wie für Objekttypen (siehe E.B.B-1.3). E.B.B-3.3 Beziehung zu Aufgabe Ein Begriffssystem kann die gleichen Beziehungen zu Aufgaben wie ein Objekttyp haben (siehe E.B.B-1.4). E.B.B-3.4 Interebenenbeziehungen zu Anwendungsbausteinen, Sendeschnittstellen, Empfangsschnittstellen und Kmmunikatinsverbindungen Ein Begriffssystem besitzt die gleichen Interebenenbeziehungen wie Objekttypen (siehe E.B.B-1.5 und E.B.B-1.6). E.B.B-3.5 Fragen des Infrmatinsmanagements und Unterstützung durch den 3LGM²-Baukasten Fragen des Infrmatinsmanagements Verweis auf Text Welche Aufgaben sind auf Verfügbarkeit eines Begriffssystems angewiesen? E.B.B-2.3, E.B.B- 1.4 W wird das Begriffssystem gespeichert? E.B.B-3.4, E.B.D- 1.8 Welche Begriffssysteme werden in der Organisatin verwendet? Gibt es ausreichende Kmmunikatinsmöglichkeiten, um Begriffssysteme vn den Anwendungsbausteinen, in denen sie gespeichert werden, zu den Anwendungsbausteinen zu kmmunizieren, in denen sie zur Erledigung vn Aufgaben benötigt werden? Welche semantische Dmäne hat ein Begriffssystem, d. h. in welchen Anwendungsbausteinen wird das Begriffssystem benötigt? E.B.B-3.1 [17] [16] 24

27 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.B-3.6 Mdellierungshinweise Bei der Mdellierung und insbesndere der Bezeichnung vn Begriffssystemen sind die Hinweise in E.B.B-1.8 zu beachten. E.B.B-4 Nutzung E.B.B-4.1 Beschreibung des Knzepts Für das Infrmatinsmanagement ist es wichtig zu wissen, welche Anwendungsbausteine, d. h. Anwendungssysteme der Organisatinssysteme, die Mitarbeiter der Organisatin bei der Erledigung ihrer Aufgaben nutzen und b möglicherweise in unterschiedlichen Organisatinseinheiten für die Erledigung derselben Aufgabe unterschiedliche Werkzeuge genutzt werden. Darüber hinaus können die Funktinen eines Anwendungssystems durch ein anderes Anwendungssystem (z. B. Webbrwser der Terminalserver) vermittelt werden, s dass sie an bestimmten Arbeitsplätzen genutzt werden können. Nutzung Die Klasse Nutzung vermittelt zwischen Aufgaben, Organisatinseinheiten und Anwendungsbausteinen. Durch die Klasse Nutzung kann beschrieben werden, welche Anwendungssysteme bei der Erledigung vn Aufgaben genutzt werden. Zusätzlich kann über diese Klasse die Verbindung zu Organisatinseinheiten hergestellt werden. Wenn eine Aufgabe in einer der mehreren Organisatinseinheiten durch mehrere Anwendungsbausteine unterstützt wird, bedeutet dies stets, dass diese Anwendungsbausteine gleichermaßen und damit alternativ zur Erledigung der Aufgaben genutzt werden können. (siehe auch E.B.B-2.4). Eine slche Mdellierung drückt damit eine funktinale Redundanz aus. Durch die Assziatinsklasse Unterstützung, welche die Assziatin zwischen Nutzung und Anwendungsbaustein näher spezifiziert, kann beschrieben werden, dass die Erledigung einer Aufgabe durch ein zugangsvermittelndes Anwendungssystem unterstützt wird, welches die Nutzung vn Funktinalität eines anderen Anwendungssystems vermittelt. Die Assziatinsklasse Unterstützung ist ebenfalls mit Organisatinseinheiten assziiert, s dass ausgedrückt werden kann, welches Anwendungssystem in welcher Organisatinseinheit die Nutzung eines anderen Anwendungssystems vermittelt. Es können smit ebenfalls Redundanzen vn zugangsvermittelnden Anwendungssystemen auftreten, wenn in unterschiedlichen Organisatinseinheiten unterschiedliche zugangsvermittelnde Anwendungssysteme genutzt werden, um die Nutzung desselben Anwendungssystems vermitteln. E.B.B-4.2 Beziehung erledigt zu Aufgabe Wenn ein Anwendungsbaustein in einer Organisatinseinheit den Mitarbeitern zur Verfügung gestellt wird, dann können ihn die Mitarbeiter drt bei der Erledigung bestimmter Aufgaben nutzen. E.B.B-4.3 Beziehung wird genutzt durch zu Organisatinseinheit Möglicherweise ist vrgesehen, dass ein Anwendungsbaustein zwar die Mitarbeiter bei einer Vielzahl vn Aufgaben unterstützen kann, aber in unterschiedlichen Organisatinseinheiten nur jeweils individuelle Teilmengen dieser Aufgaben unterstützt werden (sllen). Durch die Beziehung wird genutzt durch kann jeder einzelnen Nutzungsbeziehung zwischen Aufgabe und Anwendungsbaustein eine Organisatinseinheit zugerdnet werden. E.B.B-4.4 Interebenenbeziehung wird unterstützt vn zu Anwendungsbaustein Mit dieser Beziehung kann dargestellt werden, dass die Erledigung einer Aufgabe in verschiedenen Organisatinseinheiten durch die Nutzung vn Anwendungsbausteinen unterstützt wird. Wenn ein Anwendungssystem nicht direkt zur Erledigung einer Aufgabe genutzt werden kann, jedch den Zugang zu dem Anwendungssystem ermöglicht, das für die zu erledigende Aufgabe genutzt wird, s kann dies durch die Assziatinsklasse Unterstützung ausgedrückt werden, welche der Beziehung wird vermittelt durch zugerdnet ist (siehe Beispiel in E.B.D und Abbildung 11). E.B.B-4.5 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Verweis auf Text Werden zur Erledigung einer bestimmten Aufgabe unterschiedliche Anwendungsbausteine eingesetzt? E.B.B-2 25

28 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Werden für dieselbe Aufgabe in unterschiedlichen Organisatinseinheiten unterschiedliche Anwendungsbausteine eingesetzt? Wzu dient ein bestimmter Anwendungsbaustein? Wird für eine bestimmte Aufgabe ein mdernes Anwendungssystem genutzt? E.B.B-2 E.B.D-1.6 E.B.B-2.4 E.B.B-4.6 Mdellierungshinweise Über das Knzept Nutzung und die Interebenenbeziehung wird unterstützt durch zu Anwendungsbausteinen können einer Aufgabe mehrere Anwendungsbausteine zugerdnet werden. Damit kann aber nicht ausgedrückt werden, dass für die Unterstützung einer bestimmten Aufgabe mehrere bestimmte Anwendungsbausteine erfrderlich sind und z. B. bei dem Ausfall eines der Anwendungsbausteine die Erledigung der Aufgabe nicht mehr möglich wäre. Wenn dies ausgedrückt werden sll, muss die Aufgabe in Unteraufgaben zerlegt werden, die jeweils durch eines der Anwendungsbausteine vllständig unterstützt werden können. Diese Unteraufgaben werden dann eine Kmpsitin bilden. Einer Aufgabe sllte immer mindestens ein Anwendungsbaustein zugerdnet sein, durch welchen sie unterstützt wird, außer die Aufgabe kann durch das Infrmatinssystem nicht unterstützt werden. Die Nutzung eines zugangsvermittelnden Anwendungssystems über die Assziatinsklasse Unterstützung braucht nicht mdelliert zu werden. Durch dessen Mdellierung kann aber hervrgehben werden, dass die Funktinalität des Anwendungssystems, dass die Aufgabe unterstützt, nicht direkt genutzt werden kann. Ist einer Aufgabe swhl ein Anwendungssystem zugerdnet, das sie unterstützt, als auch über die Assziatinsklasse Unterstützung ein Anwendungssystem, das die Funktinalität eines anderen Anwendungssystems zur Erledigung der Aufgabe vermittelt, dann brauchen diese beiden Anwendungsbausteine auf der Lgischen Werkzeugebene keine Kmmunikatinsverbindung haben. Allerdings müssen die entsprechenden Physischen Datenverarbeitungssysteme, auf denen die Anwendungsbausteine installiert sind, miteinander verbunden sein. E.B.B-4.7 Kmpatibilität zu 3LGM² V1.x Dieses Knzept ersetzt die Anwendungsbausteinknfiguratinen. E.B.B-5 Organisatinseinheit E.B.B-5.1 Beschreibung des Knzepts Die unterschiedliche Unterstützung einer Aufgabe durch verschiedene Anwendungssysteme ist häufig an unterschiedliche Verantwrtungsbereiche der Organisatin gebunden. Die Kenntnis dieser Verantwrtungsbereiche ist für das Infrmatinsmanagement wichtig, um erkennen zu können, mit welchen Verantwrtlichen z. B. bei der Reduzierung funktinaler Redundanz (vgl. [22]) zu sprechen ist. Definitin: Organisatinseinheit Eine Organisatinseinheit ist eine durch Verantwrtlichkeiten abgrenzbare rganisatrische Gliederung einer Organisatin. Auch eine Organisatin, z. B. ein Krankenhaus, kann Organisatinseinheit in Bezug auf einen Verbund der ein System vn Krankenhäusern z. B. in einer Regin sein. Beispiele für Organisatinseinheiten in Krankenhäusern sind: Abteilung für Transplantatinschirurgie, Stabstelle Unternehmenskmmunikatin, Abteilung Patientenverwaltung, gemeinsamer Operatinsbereich der Abteilung für HNO und der Abteilung für Augenheilkunde. Organisatinseinheiten dürfen nicht mit Räumen der Standrten verwechselt werden (vgl. E.B.E-3.1). Auch wenn bei Bedarf ein 3LGM²-Mdell dazu genutzt werden kann zu beschreiben, welche Organisatinseinheiten welche Aufgaben erledigen, hne dabei auf die jeweilige Werkzeugunterstützung einzugehen, dient dieses Knzept in 3LGM²-Mdellen primär dazu, aufdecken zu können, w und vn wem dieselbe Aufgabe mit unterschiedlichen Werkzeugen erledigt wird. Über das Knzept Nutzung (siehe E.B.B-4) kann mdelliert werden, dass eine Aufgabe in unterschiedlichen Organisatinseinheiten durch Nutzung verschiedener Anwendungsbausteine unterstützt wird. Über die Assziatinsklasse Unterstützung kann zusätzlich mdelliert werden, dass die Nutzung eines Anwendungssystems im Rahmen einer Aufgabe auch durch verschiedene Anwendungssysteme vermittelt wird. 26

29 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.B-5.2 Zerlegung vn Organisatinseinheiten E.B.B Knzept Eine Organisatinseinheit kann durch Zerlegung in Unterrganisatinseinheiten zerlegt werden. Eine Spezialisierung, wie beispielweise für Aufgaben der Objekttypen möglich, ist bei Organisatinseinheiten nicht möglich. Unterrganisatinseinheiten werden auch als Teilrganisatinseinheiten bezeichnet, da sie immer eine Zerlegung einer Gruppenrganisatinseinheit in Teile bedeuten. Eine Organisatinseinheit kann Unterrganisatinseinheit genau einer Gruppenrganisatinseinheit sein. E.B.B Vererbung Alle Eigenschaften und Assziatinen, die einer Gruppenrganisatinseinheit zugewiesen werden, werden auch für ihre Teilrganisatinseinheiten als gegeben angesehen, d. h. die Eigenschaften und Assziatinen werden vererbt. Dies bedeutet, dass alle Beziehungen zu Nutzungen, die für die Gruppenrganisatinseinheit mdelliert sind, auch für alle ihre Teilrganisatinseinheiten als mdelliert gelten, als vererbt werden. E.B.B Vergröbern Die Teilrganisatinseinheiten einer Gruppenrganisatinseinheit G können durch Vergröbern vrübergehend inhaltlich und visuell ausgeblendet werden Bei dem Vergröbern der Teilrganisatinseinheiten einer Gruppenrganisatinseinheit werden die Teilrganisatinseinheiten (vrübergehend) aus dem Mdell entfernt. Dies bedeutet, dass auf die differenzierte Betrachtung, die durch die Teilrganisatinseinheiten gegeben ist, verzichtet wird. Die Assziatinen der Teilrganisatinseinheiten zu Nutzung werden dann für die Dauer der Vergröberung vllständig der Gruppenrganisatinseinheit zugerdnet. E.B.B-5.3 Beziehung zu Nutzung Diese Beziehung drückt aus, in welcher Organisatinseinheit Anwendungsbausteine für die Erledigung vn Aufgaben genutzt werden. E.B.B-5.4 Beziehung zu Unterstützung Durch diese Beziehung kann ausgedrückt werden, dass die Nutzung eines Anwendungssystems in einer Organisatinseinheit durch bestimmte (andere) Anwendungssysteme unterstützt wird. E.B.B-5.5 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Welche Anwendungsbausteine werden in einer bestimmten Organisatinseinheit zur Unterstützung vn Aufgaben eingesetzt? Wird eine bestimmte Aufgabe, die in einer Organisatinseinheit mit einem bestimmten Anwendungsbaustein unterstützt wird, in einer anderen Organisatinseinheit mit einem anderen Anwendungsbaustein unterstützt? Wird ein Anwendungsbaustein in verschiedenen Organisatinseinheiten zur Unterstützung unterschiedlicher Aufgaben eingesetzt? Verweis auf Text E.B.D-1 E.B.B-2.4 E.B.D-1.6 E.B.B-5.6 Mdellierungshinweise Das Vererbungsprinzip ist stets srgfältig zu beachten. S ist stets zu beachten, dass z. B. eine Beziehung die eine Gruppenrganisatinseinheit mit einer Nutzung hat, auch für alle Teilrganisatinseinheiten gegeben ist. Dies gilt auch dann, wenn einer Organisatinseinheit erst später Teilrganisatinseinheiten zugerdnet werden, als die Organisatinseinheit zur Gruppenrganisatinseinheit wird. Es wird jedch nicht immer davn auszugehen sein, dass alle Eigenschaften der Gruppenrganisatinseinheit auch für alle (neuen) Teilrganisatinseinheiten gelten. Es sllte als immer überprüft werden, b wirklich nur die Eigenschaften bei der neuen Gruppenrganisatinseinheit belassen wrden sind, die auch wirklich für alle Teilrganisatinseinheiten gelten sllen. Diese Situatin ergibt sich z. B., wenn Organisatinseinheiten eines 27

30 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Referenzmdells in ein Mdell übernmmen, drt aber zur präziseren Mdellierung aufgeteilt werden. Grundsätzlich sllte als vermieden werden, Gruppenrganisatinseinheiten Beziehungen zuzuweisen. E.B.B-6 Przesse E.B.B-6.1 Beschreibung des Knzepts Während die bisher beschriebenen Knzepte der Fachlichen Ebene die Datenverarbeitung aus der statischen Sicht betrachtet haben, sllen Przesse die Fachliche Ebene um dynamische Aspekte erweitern. Dazu werden datenverarbeitende Aufgaben, die Objekttypen bearbeiten und interpretieren, in eine lgische und zeitliche Reihenflge gebracht. Dadurch besteht in 3LGM²-Mdellen auch die Möglichkeit zu untersuchen, b die Sequenz vn datenverarbeitenden Aufgaben innerhalb des Przesses durch die Infrmatinssystemarchitektur unterstützt wird. D. h. es kann analysiert werden, b es Kmmunikatinspfade zwischen Anwendungssystemen gibt, über die Objekttypen kmmuniziert werden können, die vn aufeinanderflgenden Aufgaben bearbeitet und interpretiert werden. Definitin Przess Ein Przess (genauer: Infrmatinsprzess) ist eine Abflge vn Aufgaben, die Daten über Objekte interpretieren der bearbeiten. Um einen echten Infrmatinsprzess zu definieren, müssen alle Aufgaben (bis auf die erste) wenigstens einen Objekttyp interpretieren, der durch eine der Vrgängeraufgaben in dem Przess bearbeitet wurde. Nur dann stehen die Aufgaben aus der Sicht des Infrmatinssystems in einem sinnvllen Przesszusammenhang [24]. Durch den hier vrgestellten Przessbegriff wird im Metamdell besnders der datenverarbeitende Aspekt während des Przesses und damit die Beziehung des Przesses zur Lgischen Werkzeugebene hervrgehben. In Abbildung 8 ist ein Behandlungsablauf in der Radilgie als Przess dargestellt. Nach der administrativen Patientenaufnahme, bei der die ADT-Infrmatin des Patienten bearbeitet wird, kann die Anfrderung für die Radilgie erstellt werden, für die die ADT-Infrmatin des Patienten benötigt wird. Durch die Terminvergabe entsteht ein terminierter Einzelauftrag. Die Anfrderung und der terminierte Einzelauftrag werden durch die Radilgische Diagnstik interpretiert. Zur Radilgischen Diagnstik gehört die Radilgische Bilderzeugung, bei der das Radilgische Bild entsteht, und die Radilgische Bildbefundung, bei der das Bild interpretiert wird. Abbildung 8: Beispielprzess Radilgischer Behandlungsablauf 28

31 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.B-6.2 Snderstellung vn Przessen E.B.B Knzept Przesse unterscheiden sich vn den anderen Begriffen insfern, als ihre Existenz an die Existenz einer anderen Elementklasse (d. h. an Aufgaben) gebunden ist und sie Elemente dieser Elementklasse gruppieren und dabei in eine zeitliche Reihenflge bringen. Assziatinen vn Przessen zu sich selbst sind nicht vrgesehen. E.B.B-6.3 Beziehung zu Aufgaben Ein Przess ist im Metamdell dadurch charakterisiert, dass innerhalb vn ihm mindestens eine Aufgabe ausgeführt wird. Dabei gilt: Bei aufeinanderflgenden datenverarbeitenden Aufgaben muss die erste Aufgabe einen Objekttyp bearbeiten, der vn einer der nächsten Aufgaben interpretiert wird. Weiterhin darf keine Aufgabe, die zum Przess gehört, Unteraufgabe einer anderen Aufgabe innerhalb des Przesses sein. E.B.B-6.4 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Treten bei einem datenverarbeitenden Przess Medienbrüche auf, d. h. werden Daten zwischen rechnerbasierten Anwendungsbausteinen und papierbasierten Organisatinssystemen ausgetauscht? Hat das Infrmatinssystem eine geeignete Infrastruktur (Kmmunikatinsverbindungen, Schnittstellen, Anwendungsbausteine) für den Transprt vn Daten? Werden zusätzlich geplante Kmpnenten hinreichend sein, um die benötigte Infrastruktur zur erschaffen? Verweis auf Text E.B.D-1 E.B.D-1, E.B.D-3 E.B.B-6.5 Mdellierungshinweise Aufgaben innerhalb eines Przesses dürfen nicht in einer Ist-Teil-Vn- der Spezialisierungsbeziehung zueinander stehen. 29

32 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.C Zentrale Begriffe der Lgischen und Physischen Werkzeugebene In diesem Abschnitt werden die Begriffe Physisches Datenverarbeitungssystem, Anwendungsbaustein, Anwendungssystem und Organisatinssystem eingeführt. Mdellierungshinweise, Beziehungen der Begriffe untereinander und zu weiteren Begriffen, swie weitere Begriffe der Lgischen bzw. Physischen Werkzeugebene flgen in E.B.D bzw. E.B.E. E.B.C-1 Physisches Datenverarbeitungssystem Als datenverarbeitende Werkzeuge zur Unterstützung bei der Erledigung vn Aufgaben werden zunächst physisch greifbare und damit lkalisierbare technische Dinge bzw. Gerätschaften benötigt. Mit diesen Werkzeugen müssen die Daten, welche die Infrmatinen über Objekte darstellen, und ihre Datenträger gehandhabt werden können. Hierfür sind z. B. PC, Server, Kmmunikatinsnetzkmpnenten der Regalanlagen, Transprtfahrzeuge für Akten usw. geeignet. In mdernen rechnerbasierten Infrmatinssystemen werden häufig physisch greifbare Geräte per Sftware simuliert, z. B. bei sgenannten virtuellen Servern. Definitin: Physisches Datenverarbeitungssystem (PDVS) Ein Physisches Datenverarbeitungssystem ist ein physisch greifbarer Gegenstand der ein simulierter physisch greifbarer Gegenstand, mit dem Daten entgegengenmmen, gespeichert, weitergeleitet der gezielt verändert werden können. Die Entgegennahme, Speicherung, Weiterleitung der gezielte Veränderung vn Daten wird als Verarbeitung vn Daten bezeichnet. Die Verarbeitung der Daten flgt Regeln, die vrgegeben werden können. Wir bezeichnen Physische Datenverarbeitungssysteme auch als physische Werkzeuge der Datenverarbeitung. Physische Datenverarbeitungssysteme werden der Physischen Werkzeugebene zugerdnet (siehe E.B.E-1). Zwischen ihnen können Daten über Datenübertragungsverbindungen transprtiert werden (siehe E.B.E-1.4). Rechnersysteme (PCs, Server), Mnitre, Drucker, Switches, Ruter, Subnetze, Netzwerkkarten, Netzanschlusspunkte aber auch virtuelle Server usw. sind Physische Datenverarbeitungssysteme, deren Verarbeitung vn Daten und deren Zusammenwirken durch Regeln gesteuert werden, die in Frm vn Sftware gegeben sind. Sie werden als sftwaregesteuerte Physische Datenverarbeitungssysteme bezeichnet. Insbesndere Rechnersysteme können z. B. durch Eigenschaften wie Betriebssystem, Seriennummer, Inventarnummer, Festplattenspeicher, Arbeitsspeicher, Przessr usw. näher beschrieben werden. Abbildung 9 zeigt ein Beispiel eines slchen Physischen Datenverarbeitungssystems, wie es im 3LGM²-Baukasten näher beschrieben werden kann. 30

33 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Abbildung 9: Beispiel für ein sftwaregesteuertes Physisches Datenverarbeitungssystem. Andere, auch als knventinell bezeichnete Gegenstände der Geräte für die Datenverarbeitung sind z. B. Archivregale, Psteingangs- und Pstausgangskörbe und Transprtfahrzeuge für Akten. Die Verarbeitung vn Daten in slchen knventinellen Physischen Datenverarbeitungssystemen und ihr Zusammenwirken muss vn Menschen je nach Art des Bausteins unter Anwendung gewisser Regeln gesteuert werden. Sie werden als persnengesteuerte Physische Datenverarbeitungssysteme bezeichnet. Die Regeln werden als Organisatinspläne bezeichnet. Die steuernden Menschen werden nicht als Physische Datenverarbeitungssysteme aufgefasst. Wie Physische Datenverarbeitungssysteme miteinander in Beziehung stehen, wird in Kapitel E.B.E näher beschrieben. E.B.C-2 Anwendungsbaustein, Anwendungssystem, Organisatinssystem Physische Datenverarbeitungssysteme reichen alleine nicht aus, um die Erledigung datenverarbeitender Aufgaben zu unterstützen. S ist z. B. ein PC, der alleine mit dem Betriebssystem ausgestattet ist, ebens wenig hilfreich bei der Patientenaufnahme wie ein Regal hne Archivierungsregeln, die vn entsprechendem Persnal bei der Archivierung vn Krankenakten umgesetzt werden. Vielmehr sind die genannten Regeln und eine tatsächliche Steuerung anhand dieser Regeln erfrderlich. Definitin: Anwendungsbaustein Ein Anwendungsbaustein (engl. applicatin cmpnent) ist eine Menge tatsächlich nutzbarer Regeln, welche die Datenverarbeitung in bestimmten Physischen Datenverarbeitungssystemen steuern. Regeln sind dann tatsächlich nutzbar, wenn die Erledigung bestimmter Aufgaben der die Kmmunikatin zwischen Anwendungsbausteinen damit tatsächlich unterstützt wird. Regeln, die nicht tatsächlich verwendet werden, sndern nur z. B. als nicht-installierte Sftware auf einer CD der als Muster eines Organisatinsplans in einem Ordner festgehalten bzw. beschrieben werden, bilden als nch keinen Anwendungsbaustein sndern im ersten beschriebenen Fall ein Sftwareprdukt (vgl. E.B.D-2). Anwendungsbausteine werden als lgische Werkzeuge der Infrmatinsverarbeitung bezeichnet, da sie für die Mitarbeiter der Organisatin zwar anwendbar, aber im Gegensatz zu den physischen Werkzeugen nicht physisch greifbar sind. Anwendungsbausteine werden der Lgischen Werkzeugebene zugerdnet (siehe E.B.D). Wenn die Regeln eines Anwendungsbausteins in Frm vn Sftware implementiert sind, sprechen wir vn einem Anwendungssystem: 31

34 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Definitin: Anwendungssystem (Synnym: rechnerbasierter Anwendungsbaustein) Ein Anwendungssystem (engl. applicatin system) ist ein Anwendungsbaustein, bei dem die nutzbaren Regeln durch ein Sftwareprdukt repräsentiert sind. Ein Anwendungssystem wird als realisiert durch die Installatin, Adaptatin und Inbetriebnahme vn Sftwareprdukten auf durch Sftware steuerbaren Physischen Datenverarbeitungssystemen. Slche Physischen Datenverarbeitungssysteme sind z. B. Rechnersysteme. Während das Sftwareprdukt als eine eher abstrakte Repräsentatin vn Regeln aufgefasst werden kann, wie bestimmte Arten vn Physischen Datenverarbeitungssystemen arbeiten und zusammenwirken könnten, sind bei einem Anwendungssystem die Regeln knkretisiert und es ist explizit und knkret festgelegt, welche bestimmten Physischen Datenverarbeitungssysteme in einer bestimmten Organisatin gesteuert werden und zusammenwirken sllen. Das Synnym rechnerbasierter Anwendungsbaustein wird vrzugsweise dann verwendet, wenn deutlich gemacht werden sll, dass das Anwendungssystem als ein Teil der Mdul eines größeren Systems aufzufassen ist. Wenn die Regeln eines Anwendungsbausteins nicht in Frm vn Sftware implementiert sind bzw. sich die verwendeten Physischen Datenverarbeitungssysteme nicht mit Hilfe vn Sftware steuern lassen, müssen die Physischen Datenverarbeitungssysteme durch die Anwendung vn Organisatinsplänen gesteuert werden. Die Organisatinspläne werden vn Menschen angewendet. Definitin: Organisatinssystem Ein Organisatinssystem (engl. rganizatinal system) ist ein Anwendungsbaustein, bei dem die nutzbaren Regeln durch Organisatinspläne repräsentiert sind. Das Organisatinssystem entsteht als nach der impliziten der expliziten Verabschiedung vn Organisatinsplänen in dem Mment, w Menschen mit der Anwendung dieser Organisatinspläne beginnen. Ein Organisatinsplan kann ein schriftliches Dkument sein, in dem in Frm vn Arbeitsanweisungen beschrieben ist, wie bestimmte Aufgaben zu erledigen sind. In den meisten Fällen wird es sich aber eher um mündliche Vereinbarungen handeln. Organisatinssysteme haben eine gewisse Ähnlichkeit mit sgenannten Arbeitssystemen im Sinne der REFA [25] 5 [26]. Auch Arbeitssysteme gehen vn der Existenz vn Organisatinssystemen aus. Ein Arbeitssystem erhielte man z. B., wenn man zu einem Organisatinssystem die vn ihm gesteuerten Physischen Datenverarbeitungssysteme und die Menschen hinzunähme, die Organisatinspläne anwenden swie die, die bei der Erledigung der Aufgaben unterstützt werden. E.B.D Lgische Werkzeugebene Die lgischen Werkzeuge, als insbesndere die Anwendungsbausteine werden in der Lgischen Werkzeugebene beschrieben. Auf der Lgischen Werkzeugebene stehen die Anwendungsbausteine im Mittelpunkt. Sie beschreibt, wmit die Erledigung vn Aufgaben unterstützt wird, w Daten über Objekttypen lgisch gespeichert werden und wie Anwendungsbausteine kmmunizieren müssen, um zu gewährleisten, dass bei der Erledigung vn Aufgaben die benötigten Objekttypen tatsächlich bearbeitbar sind. E.B.D-1 Anwendungsbaustein E.B.D-1.1 Beschreibung des Knzepts Siehe E.B.C-2 E.B.D-1.2 Spezialisierung vn Anwendungsbausteinen Ein Anwendungsbaustein kann Anwendungssystem der Organisatinssystem sein. Diese Spezialisierung vn Anwendungsbausteinen ist Teil des Metamdells. Siehe E.B.C

35 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.D-1.3 Zerlegung vn Anwendungsbausteinen E.B.D Knzept Ein Anwendungsbaustein (Gruppenanwendungsbaustein) kann durch Zerlegung in Unteranwendungsbausteine zerlegt werden. Diese Unteranwendungsbausteine sind als echte Teile des zugehörigen Gruppenanwendungsbausteins zu verstehen und werden auch als Teilanwendungsbausteine bezeichnet. Ein Anwendungsbaustein kann nur Teilanwendungsbaustein eines einzigen Gruppenanwendungsbausteins sein. Ein Organisatinssystem kann Organisatinssysteme, aber auch Anwendungssysteme als Teile enthalten. Auf diese Weise können z. B. alle Anwendungssysteme eines Infrmatinssystems (z. B. eines Krankenhausinfrmatinssystems) zu einem Organisatinssystem zusammengefasst werden, das dann wiederum als Anwendungsbaustein eines übergerdneten Infrmatinssystems (z. B. reginales Gesundheitsinfrmatinssystem) aufgefasst werden könnte. Anwendungssysteme können allerdings nur aus anderen Teilanwendungssystemen bestehen. E.B.D Vererbung Alle Eigenschaften, die einem Anwendungsbaustein zugewiesen werden, werden auch für seine Teilanwendungsbausteine als gegeben angesehen (Vererbung). Für die Vererbung gilt insbesndere: Ist für einen Anwendungsbaustein die Speicherung eines Objekttyps mdelliert, wird davn ausgegangen, dass auch alle Teilanwendungsbausteine Zugriff auf die Daten zu diesem Objekttyp haben. Ist ein Anwendungsbaustein ein Master des Objekttyps, dann gelten auch alle Teilanwendungsbausteine als Master des Objekttyps. Besitzt ein Anwendungsbaustein eine Kmmunikatinsschnittstelle, wird davn ausgegangen, dass auch alle Teilanwendungsbausteine diese Kmmunikatinsschnittstelle nutzen können. Hat ein Anwendungsbaustein eine Beziehung zur Nutzung, wird davn ausgegangen, dass auch alle Teilanwendungsbausteine zu dieser Nutzung in Beziehung stehen. Die Kmpsitin bedeutet hier, dass alle Teilanwendungsbausteine unbedingt erfrderlich sind, damit der zusammenfassende Anwendungsbaustein tatsächlich die Aufgabe unterstützen kann (vgl. differierendes Knzept in E.B.E-1.2). Basiert ein Anwendungssystem auf einem Sftwareprdukt, wird davn ausgegangen, dass auch alle Teilanwendungssysteme auf diesem Sftwareprdukt basieren. Diese Regeln erfrdern im Einzelfall eine srgfältige Abwägung, b slche Eigenschaften bzw. Beziehungen für Anwendungsbausteine mdelliert werden sllen, die aus Teilanwendungsbausteinen bestehen der b diese Eigenschaften besser unmittelbar den Teilanwendungsbausteinen zugerdnet werden sllen. E.B.D Vergröbern Bei dem Vergröbern eines Gruppenanwendungsbausteins werden seine Teilanwendungsbausteine (vrübergehend) aus dem Mdell entfernt. Dies bedeutet, dass auf die differenzierte Betrachtung, die durch die Teilanwendungsbausteine gegeben ist, verzichtet wird. Die Assziatinen der Teilanwendungsbausteine zu Objekttyp, Nutzung, Physischem Datenverarbeitungssystem und Kmmunikatinsschnittstelle werden dann für die Dauer der Vergröberung dem Gruppenanwendungsbaustein zugerdnet. E.B.D-1.4 Beziehung basiert auf zu Sftwareprdukt Diese Beziehung besteht nur für Anwendungssysteme. Ein Anwendungssystem kann auf mehreren Sftwareprdukten basieren. Allerdings ist nicht vrgesehen, dass dann näher spezifiziert wird, welche Funktinalitäten des Anwendungssystems durch die einzelnen Sftwareprdukte realisiert werden. Ist dies aber gewünscht, z. B. um zu verdeutlichen, dass die Sftware SQL das Datenbanksystem des Anwendungssystems verwaltet, während die Sftware ArchiMed die Funktinalität realisiert, die für die Erledigung der Aufgaben erfrderlich ist, sllte das Anwendungssystem in zwei entsprechende Teilanwendungssysteme zerlegt werden (siehe E.B.D-1.3.1). Der Zusammenhang Anwendungssystem Sftwareprdukt sll an flgendem Beispiel verdeutlich werden: Wenn ein Krankenhaus z. B. ein Sftwareprdukt für die Archivverwaltung in Patientenaktenarchiven, nennen wir es ArchiMed, vn der Firma Graecia GmbH kauft, ist das Sftwareprdukt zunächst leer. Die Disketten der CD-ROMs, die an 33

36 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B verschiedene Krankenhäuser ausgeliefert werden, haben üblicherweise denselben Inhalt. Die krankenhausspezifischen Anpassungen müssen erst nch durchgeführt werden, z. B. muss parametriert werden, d. h. mit Daten gefüllt, wie die Akten srtiert werden, welche Abteilungen es gibt mit welchen Kstenstellennummern, auch natürlich, wie das Krankenhaus heißt, damit der Name auf dem Bildschirm der auf Briefen erscheinen kann. Nach diesen Anpassungen - auch Adaptierung genannt -, der Installatin und der Inbetriebnahme, wird aus dem Sftwareprdukt ArchiMed der Firma Graecia GmbH ein für dieses Krankenhaus spezifisches und nutzbares Anwendungssystem, das etwa als Archivverwaltungssystem bezeichnet werden kann. E.B.D-1.5 Beziehung besitzt zu Kmmunikatinsschnittstelle Ein Anwendungsbaustein kann mit anderen Anwendungsbausteinen durch den Versand bzw. das Empfangen vn Daten kmmunizieren. Für diese Kmmunikatin benötigt der Anwendungsbaustein Kmmunikatinsschnittstellen. Es wird unterschieden, b eine Kmmunikatinsschnittstelle als Sendeschnittstelle zum Senden der als Empfangsschnittstelle zum Empfangen vn Daten dient. Eine Kmmunikatinsschnittstelle existiert nur im Zusammenhang mit einem bestimmten Anwendungsbaustein. Kmmunikatinsschnittstellen vn Anwendungssystemen sind Installatinen vn Kmmunikatinssftware und als slche über die Identifikatin der Sftware abgrenzbar und identifizierbar. Kmmunikatinsschnittstellen vn Organisatinssystemen sind in der Regel in der jeweiligen Organisatin nicht eindeutig lkalisierbar der abgrenzbar. In einem Mdell sllen die Kmmunikatinsschnittstellen eines Organisatinssystems daher auch nicht einen lkalisierbaren der abgrenzbaren Teil der Organisatin repräsentieren, der für das Senden der Empfangen vn Daten zuständig wäre. Vielmehr repräsentiert eine Kmmunikatinsschnittstelle eines Organisatinssystems abstrakt die Möglichkeit des Organisatinssystems, Daten an andere Anwendungsbausteine abzugeben (zu senden) der sie entgegenzunehmen (zu empfangen). E.B.D-1.6 Interebenenbeziehung unterstützt zu Nutzung Die Beziehung beschreibt, wfür ein Anwendungsbaustein in verschiedenen Organisatinseinheiten genutzt werden kann. Es kann durchaus sein, dass ein Anwendungsbaustein in der gleichen Organisatinseinheit der auch in verschiedenen Organisatinseinheiten zur Erledigung unterschiedlicher Aufgaben eingesetzt werden kann. E.B.D Kmpatibilität zu 3LGM² V1.x Diese Beziehung ersetzt die Anwendungsbausteinknfiguratinen. E.B.D-1.7 Interebenenbeziehung vermittelt zu Unterstützung Die Beziehung besteht nur für Anwendungssysteme und beschreibt, dass ein sgenanntes zugangsvermittelndes Anwendungssystem die Nutzung eines anderen Anwendungssystems vermittelt. Es besteht die Möglichkeit, dass in verschiedenen Organisatinseinheiten verschiedene zugangsvermittelnde Anwendungssysteme zur Nutzung desselben Anwendungssystems verwendet werden. Ein zugangsvermittelndes Anwendungssystem kann jedch auch die Nutzung verschiedener Anwendungssysteme vermitteln. E.B.D-1.8 Interebenenbeziehung speichert zu Objekttyp Anwendungsbausteine werden nicht nur bei der Erledigung vn Aufgaben genutzt, sndern auch zur Speicherung vn Daten. Die Mdellierung des Speicherns eines Objekttyps in einem Anwendungsbaustein drückt aus, dass Daten über Objekte dieses Objekttyps in dem Anwendungsbaustein gespeichert werden. Ein Anwendungsbaustein wird als Master eines bestimmten Objekttyps bezeichnet, wenn Daten über Objekte dieses Objekttyps in diesem Anwendungsbaustein verändert werden dürfen. Ein Objekttyp kann mehrere Master haben. Diese Mdellierung ist wichtig, um bei der redundanten Speicherung vn Daten über Objekte dieses Objekttyps deutlich zu machen, dass nach dem Ändern dieser Daten diese Daten vn dem Master nch an alle anderen Anwendungsbausteine geleitet werden müssen, die diese Daten redundant speichern. Wenn es zu einem Objekttyp mehrere Master gibt, ist ein aufwändiges Transaktinsprtkll, z. B. das 2-phase-cmmit Prtkll, erfrderlich, um die Integrität der Daten in dem Master sicherzustellen. Dies gilt nicht nur für Anwendungssysteme, sndern auch für Organisatinssysteme. Zur Mdellierung vn Datenbanksystemen siehe E.B.D

37 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.D-1.9 Interebenenbeziehungen benötigt für Funktinalität und benötigt für Speicherung zu Physischem Datenverarbeitungssystem Ein Anwendungsbaustein wird genutzt zur Erledigung vn Aufgaben und zur Speicherung vn Daten. Für beide Zwecke werden bestimmte Physische Datenverarbeitungssysteme benötigt, in denen dann der Anwendungsbaustein die Datenverarbeitung anhand seiner Regeln steuert (vgl. Definitin in E.B.C-2). Über die Assziatin benötigt für Funktinalität werden einem Anwendungsbaustein ein der mehrere Physische Datenverarbeitungssysteme zugerdnet, die für die Entgegennahme, Weiterleitung der gezielte Veränderung vn Daten erfrderlich sind (vgl. Definitin in E.B.C-1). Über die Assziatin benötigt für Speicherung werden einem Anwendungsbaustein ein der mehrere Physische Datenverarbeitungssysteme zugerdnet, die für die Speicherung vn Daten erfrderlich sind (vgl. Definitin in E.B.C- 1). Werden dem Anwendungsbaustein mehrere Physische Datenverarbeitungssysteme über eine der beiden Assziatinen zugerdnet, bedeutet dies, dass alle jeweils zugerdneten Physischen Datenverarbeitungssysteme erfrderlich sind um die Funktinalität des Anwendungsbausteins bzw. die Datenspeicherung in dem Anwendungsbaustein zu ermöglichen. Mehrere Physische Datenverarbeitungssysteme können über die Beziehung wird virtualisiert zu einem virtuellen Physischen Datenverarbeitungssystem bzw. Cluster gruppiert werden (siehe E.B.E-1.3). Wird einem Anwendungsbaustein der Cluster zugerdnet, wird damit ausgedrückt, dass nicht alle der Physischen Datenverarbeitungssysteme ntwendig sind, sndern nur mindestens eines der Physischen Datenverarbeitungssysteme dieses Clusters ntwendig ist. Smit ist ein virtuelles Physisches Datenverarbeitungssystem nicht gleichzusetzen mit einem kmmerziell erhältlichen Virtualisierungssystem wie z. B. VMware, sndern es ist ein verallgemeinerndes Knzept, welches aber auch zur Mdellierung vn Virtualisierungssystemen genutzt werden kann. Wie die wird virtualisiert -Beziehung zur Mdellierung eines slchen Virtualisierungssystems genutzt wird, ist in E.B.E-1.3 beschrieben. Mit Hilfe eines Clusters kann z. B. mdelliert werden, dass ein Anwendungssystem für seine Funktinalität mindestens einen Server (aus einer Gruppe möglicherweise redundanter Rechner) und mindestens einen Client (aus einer Gruppe vn Arbeitsplatzrechnern) benötigt. Abbildung 10 zeigt die physische Basis für ein Bildbefundungssystem. Damit das Bildbefundungssystem benutzt werden kann, wird mindestens ein Server aus der Gruppe Virtuell: MagicView-Server swie mindestens eine Wrkstatin aus der Gruppe Virtuell: Befundungswrkstatins benötigt. Abbildung 10: Beispiel für die Mdellierung virtueller Physischer Datenverarbeitungssysteme 35

38 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.D-1.10 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Welche Daten, d. h. welche Daten über Typen vn Objekten werden auf welchem Server der in welchem Aktenlager gespeichert? Welche Aufgaben können nicht mehr unterstützt werden, wenn ein Anwendungsbaustein ausfällt? Hierbei ist zu berücksichtigen, dass der Anwendungsbaustein möglicherweise selber die Erledigung vn Aufgaben unterstützt der aber dafür srgt, dass Daten zu Objekten zu einem anderen Anwendungssystem transprtiert werden, die drt für die Erledigung vn Aufgaben benötigt werden. Welche Datendmäne hat ein Objekttyp, d. h. in welchen Anwendungsbausteinen wird der Objekttyp benötigt? Ist im Infrmatinssystem / in bestimmten Teilen des Infrmatinssystems Datenintegratin gegeben, d. h. müssen bestimmte Daten nur einmal erfasst werden, auch wenn die dadurch repräsentierten Infrmatinen bei der Arbeit mit mehreren Anwendungssystemen benötigt werden? Welche funktinale Dmäne hat eine Aufgabe, d. h. welche Anwendungsbausteine unterstützen eine Aufgabe? Ist im Infrmatinssystem / in bestimmten Teilen des Infrmatinssystems funktinale Integratin gegeben, d. h. sind Funktinen, die in mehreren Anwendungssystemen benötigt werden, nur einmal implementiert und können aus anderen Anwendungssystemen aufgerufen werden? Welche semantische Dmäne hat ein Begriffssystem, d. h.. in welchen Anwendungsbausteinen wird das Begriffssystem benötigt? Ist im Infrmatinssystem / in bestimmten Teilen des Infrmatinssystems semantische Integratin gegeben, d. h. werden in unterschiedlichen Anwendungssystemen dieselben Begriffssysteme verwendet und werden Daten smit gleich interpretiert? Welche Zugriffsdmänen besitzt ein physisches Datenverarbeitungssystem, d. h. welche Anwendungssysteme sind darauf installiert? Welche Anwendungssysteme meines Infrmatinssystems könnten abgeschafft werden, hne dass Funktinalität verlren geht (funktinale Redundanz)? Habe ich unnötige Ksten, weil verschiedene Nutzer in meiner Institutin verschiedene Anwendungssysteme benutzen, um die gleiche Aufgabe zu erfüllen? Was sind kritische Unternehmensaufgaben und die Nutzung welcher Anwendungssysteme sllte vermieden werden? Verweis auf Text E.B.D-1.9 E.B.B-2.4 [16] [16] [16] [16] [16] [16] [16] [27] [27] E.B.D-1.11 Mdellierungshinweise Anwendungsbausteine: Das Vererbungsprinzip ist stets srgfältig zu beachten. S ist stets zu beachten, dass z. B. eine Beziehung, die ein Anwendungsbaustein mit einem Objekttyp hat, auch für alle Teilanwendungsbausteine gegeben ist. Dies gilt auch dann, wenn einem Anwendungsbaustein erst später Teilanwendungsbausteine zugerdnet werden. Nicht immer wird jedch davn auszugehen sein, dass alle Eigenschaften des Anwendungsbausteins auch für alle Teilanwendungsbausteine gelten. Es sllte als immer überprüft werden, b wirklich nur die Eigenschaften bei dem Anwendungsbaustein belassen wrden sind, die auch wirklich für alle Teilanwendungsbausteine gelten sllen. Diese Situatin ergibt sich z. B., wenn Anwendungsbausteine eines Referenzmdells in ein Mdell übernmmen, drt aber zur präziseren Mdellierung aufgeteilt werden. Grundsätzlich sllte als vermieden werden, übergerdneten Anwendungsbausteinen Beziehungen zuzuweisen. Zur Unterstützung der Mdellierung bietet der 3LGM²-Baukasten eine Funktin, mit der alle der eine Auswahl der vererbbaren Eigenschaften und Beziehungen eines Anwendungsbausteins explizit auf alle Teilanwendungsbausteine übertragen und bei dem Anwendungsbaustein entfernt werden. Grundsätzlich sllte vermieden werden zu mdellieren, dass ein Anwendungsbaustein aus genau einem Teilanwendungsbaustein besteht. Vielmehr ist es erfrderlich, neben einem Teil des Anwendungsbausteins auch die anderen Teile explizit zu beschreiben. Dies bedeutet, dass die Verfeinerung eines 36

39 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Anwendungsbausteins aus mindestens zwei (Teil-)Anwendungsbausteinen besteht, die gemeinsam den übergerdneten Anwendungsbaustein vllständig beschreiben. Anwendungssysteme: Anwendungssysteme können durch die Sftwareprdukte, durch deren Installatin sie entstanden sind, vneinander abgegrenzt werden. Ein Anwendungssystem ist daher in der Regel ein betriebswirtschaftlich relevanter Vermögensgegenstand (Asset), da er die für seinen Betrieb erwrbenen und tatsächlich nutzbaren Sftwareprdukte repräsentiert. Im Übrigen ergibt sich daher aus der Mdellierung eines Anwendungssystems, dass für die verwendete Sftware, wenn deren Nutzung entgeltpflichtig ist, auch tatsächlich Nutzungsgebühren fällig werden. Um ein Anwendungssystem an einem Arbeitsplatzrechner nutzen zu können ist bestimmte Sftware erfrderlich, die dem Benutzer den Zugang zu dem Anwendungssystem vermittelt. Diese Sftware kann in dem vrhandenen Betriebssystem integriert sein der es ist z B. ein Internet-Brwser nötig der die Nutzung erflgt über eine Terminalemulatin und einen Terminalserver. Die Installatin der Sftware, die den Zugang zu einem Anwendungssystem vermittelt, kann bei Bedarf als zugangsvermittelndes Anwendungssystem mdelliert werden. Die Mdellierung der Beziehungen zwischen Anwendungssystemen und Aufgaben erflgt über die Klasse Nutzung und die Assziatinsklasse Unterstützung, die der Assziatin zwischen Nutzung und Anwendungsbaustein zugerdnet ist. Sll mdelliert werden, dass ein Anwendungssystem den Zugang zur Nutzung eines anderen Anwendungssystems, welches eine Aufgabe unterstützt, vermittelt, s geschieht dies über die Assziatinsklasse Unterstützung. Die direkte Unterstützung einer Aufgabe durch ein Anwendungssystem wird mdelliert über die Klasse Nutzung. Es kann hilfreich sein, eine Kmmunikatinsverbindung zu mdellieren, die alle zur Erledigung der Aufgabe erfrderlichen Objekttypen zwischen dem vermittelten Anwendungssystem und dem zugangsvermittelnden Anwendungssystem transprtiert. Allerdings ist dies nicht unbedingt nötig, wenn auf der Physischen Werkzeugebene eine Datenübertragungsverbindung zwischen den zugrundeliegenden physischen Datenverarbeitungssystemen des vermittelten und des zugangsvermittelnden Anwendungssystems hergestellt wird. In Abbildung 11 sind die Nutzung und die Unterstützung der Nutzung vn Anwendungssystemen bei der Erledigung vn Aufgaben beispielhaft dargestellt: Das Patientenverwaltungssystem ist das vermittelte Anwendungssystem, Terminalserver das zugangsvermittelnde Anwendungssystem. Die Aufgabe administrative Patientenaufnahme wird durch das Patientenverwaltungssystem unterstützt und durch den Terminalserver vermittelt. In der Kmmunikatinsverbindung zwischen KDMS und Terminalserver könnte ein Nachrichtentyp alle Objekttypen, die interpretiert werden müssen, zum Terminalserver transprtieren. Abbildung 11: Mdellierung zugangsvermittelnder Anwendungssysteme 37

40 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Die Mdellierung vn Teilanwendungssystemen sllte nicht ausschließlich dazu benutzt werden, eine Zugriffsmöglichkeit des vrgesehenen Teilanwendungssystems auf die Daten zu beschreiben, die in dem übergerdneten Anwendungssystem gespeichert sind. Die Teil-vn-Beziehung kann vielmehr dazu benutzt werden zu beschreiben, dass auch das durch die Zusammenfassung der Teile sich ergebende Gebilde als Baustein des gesamten Infrmatinssystems der auch wiederum als Asset aufzufassen ist. Für die Teilanwendungsbausteine eines Anwendungsbausteins kann bei der Mdellierung angenmmen werden, dass sie unbeschränkt untereinander Daten austauschen können. Die Mdellierung vn Kmmunikatinsverbindungen zwischen den Teilanwendungsbausteinen desselben Anwendungsbausteins würde damit auch entfallen. Möchte man jedch auch die Kmmunikatin innerhalb eines Anwendungsbausteins beschreiben, s empfiehlt es sich, für jede Kmmunikatinsschnittstelle des Anwendungsbausteins einen neuen Anwendungsbaustein mit zwei Kmmunikatinsschnittstellen eine nach innen und eine nach außen anzulegen. Wenn dargestellt werden sll, dass die unterschiedlichen Kmpnenten eines Anwendungssystems dadurch integriert werden, dass sie auf dieselbe Datenbank zugreifen, kann dies wie flgt mdelliert werden: Die Kmpnenten werden als Teilanwendungssysteme mdelliert. Insbesndere wird das aus der Datenbank und dem verwendeten Datenbankverwaltungssystem zusammengesetzte Datenbanksystem als ein Teil- Anwendungssystem mdelliert; das Datenbankverwaltungssystem wird als Sftwareprdukt mdelliert. Über Kmmunikatinsschnittstellen und Kmmunikatinsverbindungen wird dann die Kmmunikatin der Teil- Anwendungssysteme untereinander mdelliert. Der Mdellierer hat stets darauf zu achten, dass einem Anwendungssystem nur slche Physischen Datenverarbeitungssysteme zugerdnet werden, die sich auch durch Sftware steuern lassen. Organisatinssysteme: Im Gegensatz zum Anwendungssystem ist es nicht immer einfach, ein Organisatinssystem klar abzugrenzen und zu bezeichnen. Abgrenzungskriterien können z. B. die Zugehörigkeit zu einer Organisatinseinheit, die Dminanz einer bestimmten Persnengruppe (Rlle) der aber die Erledigung bestimmter Aufgaben sein. Als Bezeichnung bietet sich ft die Frm Organisatinssystem der/des/für... Im ersten Fall der Zugehörigkeit zu einer Organisatinseinheit kann es sich beispielsweise um die angewendeten Regeln zum Dkumentenmanagement auf der Statin AUG1 des Universitätsklinikums handeln. In diesem Fall könnte als Bezeichnung gewählt werden: Organisatinssystem des Dkumentenmanagements AUG1. Im zweiten Fall kann es sich beispielsweise um Regeln zur Pflegedkumentatin in der Klinik für Chirurgie 1 handeln. In diesem Fall könnte als Bezeichnung gewählt werden: Organisatinssystem der Pflegedkumentatin Chirurgie 1. Im dritten Fall kann es sich beispielsweise um das Organisatinssystem zur Archivierung vn Krankenakten handeln. In diesem Fall könnte als Bezeichnung gewählt werden: Organisatinssystem der Archivierung der auch einfach z. B. Krankenaktenarchiv. Denkbar sind auch Kmbinatinen vn Abgrenzungskriterien. Auf jeden Fall sllte beim Mdellieren eines persnengesteuerten Infrmatinsverarbeitungssystems genau festgehalten werden, welches Kriterium bzw. welche Kmbinatin vn Kriterien in welcher Frm zur Abgrenzung dienen. Ferner muss zwingend darauf geachtet werden, dass zwei Organisatinssysteme, die nicht in einer Teil-vn-Beziehung stehen (vgl. Kap. E.B.D), sich in einem Mdell nicht inhaltlich überlagern. Die Menge der Anwendungsbausteine des Infrmatinssystems einer Organisatin kann durch ein Organisatinssystem zusammengefasst und damit wieder als Anwendungsbaustein aufgefasst werden, z. B. dann, wenn das Infrmatinssystem der Organisatin als Teilsystem eines reginalen Gesundheitsinfrmatinssystems aufgefasst wird [28]. Beziehungen zwischen Anwendungsbausteinen: Gelegentlich liegen Daten in einem rechnerbasierten Anwendungssystem vr und werden in einem anderen Anwendungssystem benötigt, werden aber zur Übermittlung zuerst ausgedruckt, dann wieder am Ziel abgetippt der es wird ein Datenträger beschrieben, der am Ziel wieder eingelegt wird. In einer slchen Situatin sllte keine direkte Kmmunikatinsverbindung zwischen Kmmunikatinsschnittstellen der beiden Anwendungssysteme mdelliert werden. Vielmehr sllte der Aspekt des menschlichen Eingreifens in den Kmmunikatinsvrgang durch das Zwischenschalten mindestens eines Organisatinssystems dargestellt werden. Darauf kann verzichtet werden, wenn auf Grund des Mdellierungszwecks das menschliche Eingreifen als unbedeutend eingestuft wird. 38

41 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.D-2 Sftwareprdukt E.B.D-2.1 Beschreibung des Knzepts Ein Sftwareprdukt ist eine abgeschlssene, erwrbene der eigenentwickelte Sftware, die dediziert für die Erledigung bestimmter Aufgaben einer Klasse vn Organisatinen der für den Austausch vn Daten zwischen Anwendungssystemen bestimmt ist. Ein Betriebssystem wird z. B. dann als Sftwareprdukt aufgefasst, wenn dargestellt werden sll, dass es die Mitarbeiter der Organisatin durch bestimmte Funktinen direkt bei der Erledigung bestimmter Aufgaben unterstützt, hne dass dabei zusätzliche Sftware erfrderlich ist. Während das Sftwareprdukt als eine eher abstrakte Repräsentatin vn Regeln aufgefasst werden kann, wie bestimmte Arten vn Physischen Datenverarbeitungssystemen arbeiten und zusammenwirken könnten (vgl. Definitin Anwendungsbaustein in E.B.C-2), sind bei einem Anwendungssystem die Regeln knkretisiert und es ist explizit festgelegt, welche bestimmten Physischen Datenverarbeitungssysteme in einer bestimmten Organisatin gesteuert werden und zusammenwirken sllen. Ein Sftwareprdukt wird entweder am Markt als Standardprdukt erwrben der gezielt für den Einsatz in einer Organisatin entwickelt. Die Entwicklung des Sftwareprdukts kann in der Organisatin selbst der aber durch ein anderes Unternehmen erflgen. E.B.D-2.2 Beziehung dient als Basis für zu Anwendungssystem Durch die Installatin des Sftwareprdukts entsteht ein Anwendungssystem. Werden bei der Adaptatin des Sftwareprdukts dessen Knstruktin nicht verändert und lediglich Tabelleneinträge vrgenmmen, spricht man vn Adaptatin durch Parametrierung der engl. custmizing. In diesem Fall ist die ausführbare Sftware des Anwendungsbausteins identisch mit dem Sftwareprdukt. Ein und dasselbe Sftwareprdukt kann in einer Organisatin auch mehrfach installiert werden. Aus Sicht des Infrmatinsmanagements und gerade im Hinblick auf den erfrderlichen Integratinsaufwand muss jede dieser Installatinen als ein eigenständiges Anwendungssystem aufgefasst werden; denn auch zwei Anwendungssysteme desselben Sftwareprdukts benötigen ft auch aufwändige Kmmunikatinsschnittstellen, um einen Datenaustausch zwischen ihnen zu ermöglichen. Ein Sftwareprdukt muss nicht ntwendigerweise eine Beziehung zu einem Anwendungssystem haben. Ohne diese Beziehung kann ein Katalg vn z. B. am Markt verfügbaren der im Rahmen einer Ausschreibung angebtenen Sftwareprdukte mdelliert werden, die bestimmte Aufgaben des Infrmatinssystems der Organisatin unterstützen könnten. Erst wenn es im Rahmen entsprechender Einführungsprjekte zur Installatin eines der Sftwareprdukte käme, würde eine Beziehung zu dem dann entstandenen Anwendungssystem zu mdellieren sein. E.B.D-2.3 Interebenenbeziehung kann unterstützen zu Aufgabe Das Sftwareprdukt wurde entwickelt, um nach Installatin die Erledigung bestimmter Aufgaben einer Organisatin zu unterstützen. Bei der Installatin (vgl. E.B.D-2.2) werden aber nicht ntwendigerweise alle Möglichkeiten zur Unterstützung der Erledigung vn Aufgaben in Betrieb genmmen. Andererseits können aber auch Möglichkeiten zur Erledigung weiterer Aufgaben geschaffen werden. Mit dieser Assziatin werden als alle Aufgaben bezeichnet, deren Erledigung ein durch Installatin dieses Sftwareprdukts entstehendes Anwendungssystem unterstützen könnte. E.B.D-2.4 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Könnte auf bestimmte Anwendungssysteme in einem Infrmatinssystem verzichtet werden, wenn das Ptential der bereits eingesetzten Sftwareprdukte, die Erledigung weiterer Aufgaben zu unterstützen, mehr ausgenutzt würde? Wird das Sftwareprdukt, das als Basis des Anwendungssystems A in dem Infrmatinssystem des Krankenhauses K eingesetzt wird, auch für andere Anwendungssysteme im demselben Krankenhaus der in anderen Krankenhäusern der Regin eingesetzt? Verweis auf Text E.B.B-2.5 E.B.B

42 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Wie hch sind die Lizenzksten des Sftwareprdukts, das als Basis des Anwendungssystems A in dem Infrmatinssystem des Krankenhauses K eingesetzt wird? Wer sind die Ansprechpartner bei dem entsprechenden Hersteller/Lieferant? Welche (am Markt) verfügbaren Sftwareprdukte könnten zur Unterstützung der Erledigung einer bestimmten Menge vn Aufgaben eingesetzt werden? Könnte auf bestimmte Anwendungssysteme in einem Infrmatinssystem verzichtet werden, wenn ein bestimmtes anderes Sftwareprdukt, das die Erledigung einer größeren Menge vn Aufgaben unterstützen könnte, eingesetzt würde? E.B.B-2 E.B.B-2, E.B.D-1 E.B.D-3 Kmmunikatinsverbindung, Sende- und Empfangsschnittstelle E.B.D-3.1 Beschreibung des Knzepts Ein Anwendungsbaustein besitzt Kmmunikatinsschnittstellen um mit anderen Anwendungsbausteinen kmmunizieren zu können. Eine Sendeschnittstelle eines Anwendungssystems kann Daten an ein anderes Anwendungssystem versenden, das diese Daten über eine Empfangsschnittstelle empfangen kann. Wenn vn einer Sende- zu einer Empfangsschnittstelle tatsächlich Daten versendet werden, dann werden diese Kmmunikatinsschnittstellen durch eine Kmmunikatinsverbindung verbunden, die vn der Sende- zu der Empfangsschnittstelle weist. Eine Kmmunikatinsschnittstelle kann für eine bestimmte Art vn Daten Sendeschnittstelle und gleichzeitig für eine andere Art vn Daten Empfangsschnittstelle sein. Alle Kmmunikatinsschnittstellen eines Anwendungsbausteins gelten implizit als s untereinander verbunden, dass jede Sendeschnittstelle des Anwendungsbausteins auf alle Daten aller Empfangsschnittstellen des Anwendungsbausteins zugreifen kann. E.B.D-3.2 Interebenenbeziehungen kann senden und kann empfangen vn Sende- und Empfangsschnittstellen zu Objekttyp und überträgt vn Kmmunikatinsverbindung zu Objekttyp Die Assziatin einer Sendeschnittstelle zu einem Objekttyp beschreibt, dass diese Sendeschnittstelle Daten versenden kann, die Infrmatinen über Objekte repräsentieren, welche durch den Objekttyp beschrieben sind. Vereinfachend kann davn gesprchen werden, dass die Sendeschnittstelle den Objekttyp versenden kann. Die Assziatin einer Empfangsschnittstelle zu einem Objekttyp beschreibt, dass diese Empfangsschnittstelle Daten empfangen kann, die Infrmatinen über Objekte repräsentieren, welche durch den Objekttyp beschrieben sind. Vereinfachend kann davn gesprchen werden, dass die Empfangsschnittstelle den Objekttyp empfangen kann. Die Assziatin einer Kmmunikatinsverbindung zu einem Objekttyp beschreibt, dass diese Kmmunikatinsverbindung Daten transprtiert, die Infrmatinen über Objekte repräsentieren, welche durch den Objekttyp beschrieben sind. Vereinfachend kann davn gesprchen werden, dass die Kmmunikatinsverbindung den Objekttyp vn der Sendeschnittstelle zur Empfangsschnittstelle transprtiert. E.B.D-3.3 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Erflgt die Kmmunikatin zwischen zwei bestimmten Anwendungssystemen umständlich durch den physischen Transprt vn DVDs, CDs der gar per Papier, der werden die Nachrichten kmfrtabel auf signalbasierten Wegen wie WLAN der Kupferkabel transprtiert? Wenn ein Anwendungsbaustein Daten zu Objekten eines Objekttyps erhält und Daten zu Objekten desselben Objekttyps abgibt, müssen dann die Daten zwischen unterschiedlichen nicht signalbasierten Übertragungsmedien aufwändig umkpiert werden? Wenn ein Anwendungsbaustein Daten zu Objekten eines Objekttyps erhält und Daten zu Objekten desselben Objekttyps abgibt, findet dann ein Medienbruch zwischen signalbasierten und nicht signalbasierten Übertragungsmedien mit aufwändiger Transkriptin statt? Daten zu welchen Objekttypen werden zwischen zwei bestimmten Anwendungsbausteinen ausgetauscht? Verweis auf Text E.B.E-5 E.B.E-5 E.B.E-5 E.B.B

43 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Erhält ein bestimmter Anwendungsbaustein alle die Daten zu Objekttypen, welche die Aufgaben, die er unterstützt, interpretieren? Welche Objekttypen kann ein Anwendungsbaustein versenden der empfangen? E.B.D-1 E.B.D-1.5, E.B.D-3 E.B.D-3.4 Mdellierungshinweise Sll bei einem Anwendungsbaustein explizit dargestellt werden, wie innerhalb des Bausteins Daten vn einer Empfangs- zu einer Sendeschnittstelle geleitet und dabei möglicherweise (z. B. in einem Kmmunikatinsserver) umfrmatiert werden, kann dies wie in E.B.D-3.1 erwähnt, nicht durch eine (interne) Kmmunikatinsverbindung dargestellt werden. Zur Darstellung interner Kmmunikatin muss der Anwendungsbaustein vielmehr in Teilanwendungsbausteine aufgeteilt werden (siehe E.B.D-1), zwischen denen dann Kmmunikatinsverbindungen mdelliert werden können. Bei einem Anwendungsbaustein kann für jeden Objekttyp, den er versenden/empfangen kann, eine besndere Kmmunikatinsschnittstelle mdelliert werden. Alternativ kann auch für alle sendbaren Objekttypen eine einzige Sende- und für alle empfangbaren Objekttypen eine einzige Empfangsschnittstelle mdelliert werden. Ferner kann eine einzige Kmmunikatinsschnittstelle mdelliert werden, die als Sende- und Empfangsschnittstelle für alle versend- und empfangbaren Objekttypen dient. Es empfiehlt sich aber, auch Kmmunikatinsschnittstellen im Sinne vn Assets (vgl. E.B.D-1.11) zu mdellieren, d. h. dann eine Kmmunikatinsschnittstelle zu mdellieren, wenn diese in der mdellierten Frm vn dem jeweiligen Hersteller s hergestellt bzw. geliefert, vn der einsetzenden Organisatin bei Kauf bzw. Betrieb zu bezahlen ist und/der beim Betrieb als slche zu betreiben bzw. zu warten ist. Die explizite Mdellierung vn Kmmunikatinsverbindungen zwischen Kmmunikatinsschnittstellen desselben Anwendungsbausteins ist nicht vrgesehen E.B.D-4 Beispiel E.B.E Abbildung 12: Darstellung vn Kmmunikatinsverbindungen und Sende- und Empfangsschnittstellen Physische Werkzeugebene Die physischen Werkzeuge, als insbesndere die Physischen Datenverarbeitungssysteme, werden in der Physischen Werkzeugebene zusammengefasst. E.B.E-1 Physisches Datenverarbeitungssystem E.B.E-1.1 Siehe E.B.C-1. Beschreibung des Knzepts E.B.E-1.2 Zerlegung vn Physischen Datenverarbeitungssystemen E.B.E Knzept Ein Physisches Datenverarbeitungssystem kann durch Zerlegung in seine Unterdatenverarbeitungssysteme zerlegt werden. Diese Unterdatenverarbeitungssysteme werden auch als Teildatenverarbeitungssysteme bezeichnet. Ein Physisches Datenverarbeitungssystem kann nur Teildatenverarbeitungssystem eines einzigen Physischen Datenverarbeitungssystems sein. Es findet keine Vererbung vn Gruppendatenverarbeitungssystemen auf Teildatenverarbeitungssysteme statt. 41

44 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Ein Teildatenverarbeitungssystem gilt als nicht funktinsfähig hne das Physische Datenverarbeitungssystem, dessen Teil es ist. Beispielsweise ist eine Grafikkarte, die nicht Teil eines Rechners ist, nicht funktinsfähig. Für die Teildatenverarbeitungssysteme eines Physischen Datenverarbeitungssystems wird angenmmen, dass sie unbeschränkt untereinander Daten austauschen können. Die Mdellierung vn Datenübertragungsverbindungen zwischen den Teildatenverarbeitungssystemen desselben Physischen Datenverarbeitungssystems ist daher nicht vrgesehen. (Vgl. differierendes Knzept in E.B.E-1.3.1) E.B.E Vererbung Die Teildatenverarbeitungssysteme eines Physischen Datenverarbeitungssystems erben vn diesem Physischen Datenverarbeitungssystem keine Eigenschaften der Beziehungen! E.B.E Vergröbern Beim Vergröbern eines Physischen Datenverarbeitungssystems werden seine Teildatenverarbeitungssysteme (vrübergehend) aus dem Mdell entfernt. Dies bedeutet, dass auf die differenzierte Betrachtung, die durch die Teildatenverarbeitungssysteme gegeben ist, verzichtet wird. Die Datenübertragungsverbindungs-Assziatinen der Teildatenverarbeitungssysteme zu anderen Physischen Datenverarbeitungssystemen swie die Assziatinen zu Anwendungsbausteinen werden dem Physischen Datenverarbeitungssystem zugerdnet, dessen Teil sie sind. Die anderen Assziatinen verschwinden mit der Vergröberung. E.B.E Kmpatibilität zu 3LGM² V1.x bzw. 3LGM² V2.x Die bisherige Teil-vn-Beziehung. wurde häufig im Sinne der Kmpsitin verwendet. Bei einer Knversin zu V3.x beachte bitte F.E.C-1. E.B.E-1.3 Virtualisierung und Cluster E.B.E Knzept Durch die Assziatin virtualisiert / wird virtualisiert durch können Physische Datenverarbeitungssysteme mit anderen Physischen Datenverarbeitungssystemen in eine Beziehung gebracht werden. Über die Virtualisierungsbeziehung kann entweder ausgedrückt werden, dass ein der mehrere Physische Datenverarbeitungssysteme zusammen ein Physisches Datenverarbeitungssystem simulieren der dass ein Physisches Datenverarbeitungssystem ein der mehrere Physische Datenverarbeitungssysteme simuliert. Im ersten Fall heißt das simulierte (virtuelle) Physische Datenverarbeitungssystem Cluster. Im zweiten Fall heißen die simulierten (virtuellen) Physischen Datenverarbeitungssysteme virtuelle Maschinen. Zur Veranschaulichung siehe Abbildung 13. In einem Cluster genügt beispielsweise die Verfügbarkeit eine zugehörigen Servers, um ein Anwendungssystem ausführen. Nach außen hin kann Cluster wie ein einziger Server verwaltet werden. Im Gegensatz dazu können mit Hilfe virtueller Maschinen z. B. verschiedene Betriebssysteme der verschiedene Instanzen eines Betriebssystems parallel auf einem Server ausgeführt werden. Virtuelle Maschinen und Cluster werden als virtuelle Physische Datenverarbeitungssysteme bezeichnet. Eine Physisches Datenverarbeitungssystem kann Mitglied mehrerer Cluster sein. Für die Mitglieder eines Clusters wird im Gegensatz zu E.B.D nicht angenmmen, dass sie allein aufgrund ihrer Mitgliedschaft unbeschränkt untereinander Daten austauschen könnten. Vielmehr sind die gegebenen Kmmunikatinsmöglichkeiten explizit durch Datenübertragungsverbindungen zu mdellieren. 42

45 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Abbildung 13. Oben: Beispiel für einen Cluster, der aus drei physischen Servern besteht. Unten: Auf einem physischen Server laufen drei virtuelle Maschinen. Für die Beziehungen zu Anwendungsbausteinen sind aber flgende Besnderheiten des Clusters zu beachten (vgl. differierendes Knzept in E.B.D-1.3.2): E.B.E Hat ein Cluster C eine Beziehung wird für Funktinalität benötigt zu einem Anwendungsbaustein A, dann bedeutet die Gruppenbeziehung, dass bereits eines der Mitglieder des Clusters C ausreicht, um die Funktinalität vn A zu gewährleisten. Auf diese Weise lässt sich G als ein virtuelles Physisches Datenverarbeitungssystem, als als virtuellen Server auffassen, dessen Mitglieder der Kmpnenten die Funktinalität vn A in redundanter Weise gewährleisten. Hat ein Cluster C eine Beziehung wird für Speicherung benötigt zu einem Anwendungsbaustein A, dann bedeutet die Gruppenbeziehung, dass bereits eines der Mitglieder des Clusters C ausreicht, um die Speicherungsfähigkeit vn A zu gewährleisten. Auf diese Weise lässt sich G als ein virtuelles Physisches Datenverarbeitungssystem, als als virtuellen Speicher auffassen, dessen Mitglieder der Kmpnenten die Speicherungsfähigkeit vn A in redundanter Weise gewährleisten. Kmpatibilität zu 3LGM² V1.x, 3LGM² V2.x Die Virtualisierung hat in V1.x bzw. V2.x kein Pendant. Allerdings sind in der Mdellierungspraxis einige der Teilvn-Beziehungen s interpretiert wrden, um auf diese Weise z. B. virtuelle Maschinen darstellen zu können. Bei der Knvertierung muss im Einzelfall entschieden werden, wie die Teil-vn-Beziehungen zu übersetzen sind. Mdellierungshinweis für V1.x: Wenn die Teil-vn-Beziehung zur Mdellierung vn Gruppen verwendet wird, dann sllte ein Bausteintyp zugerdnet werden, dessen Bezeichnung mit virtuell: beginnt. Dann kann bei einer Knvertierung diese Infrmatin genutzt werden und im Mdell ist die Interpretatin klarer. Siehe F.E.C-1. E.B.E-1.4 Beziehung zur Assziatinsklasse Datenübertragungsverbindung ( übertragt Daten zu, empfängt Daten vn ) Ein Physisches Datenverarbeitungssystem kann mit anderen Physischen Datenverarbeitungssystemen durch den Austausch vn Daten kmmunizieren. Für diese Kmmunikatin benötigen zwei Physische Datenverarbeitungssysteme 43

46 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B jeweils eine Datenübertragungsverbindung. Die Datenübertragungsverbindung wird durch eine Assziatin mit der Assziatinsklasse Datenübertragungsverbindung zwischen zwei Physischen Datenverarbeitungssystemen mdelliert. Bei Bedarf kann eine Schnittstelle durch die Mdellierung eines entsprechenden Physischen Datenverarbeitungssystems dargestellt werden, das als Teil des Physischen Datenverarbeitungssystems mdelliert wird, an das die Datenübertragungsverbindung durch die Schnittstelle anzuschließen ist. E.B.E-1.5 Beziehung ist vm Typ zu Geräteklasse Physische Datenverarbeitungssysteme können über Geräteklassen klassiert werden. Dadurch hat der Mdellierer völlig freie Hand, unterschiedlichste Arten vn Physischen Datenverarbeitungssystemen zu mdellieren. Das Herstellen einer Beziehung vn einem Physischen Datenverarbeitungssystem zu einer Geräteklasse bewirkt auch, dass das Physische Datenverarbeitungssystem graphisch mit dem Icn dargestellt ist, dass der Geräteklasse zugewiesen wrden ist (falls eine slche Zuweisung erflgte). Darüber hinaus wird die Beziehung vn einem Physischen Datenverarbeitungssystem zu einer Geräteklasse nicht graphisch dargestellt. Ein Physisches Datenverarbeitungssystem kann nur zu höchstens einer Geräteklasse gehören. E.B.E-1.6 Beziehung befindet sich an zu Standrt Wenn sich ein Physisches Datenverarbeitungssystem dauerhaft an einem bestimmten Ort befindet, kann ihm dieser Ort als Standrt zugewiesen werden. Insbesndere mbilen Geräten wie Tablet-PC der PDA wird man möglicherweise keinen Standrt zuweisen. Die Beziehung wird graphisch nicht dargestellt. E.B.E-1.7 Interebenenbeziehung wird für Funktinalität benötigt zu Anwendungsbaustein Über die Assziatin wird für Funktinalität benötigt werden einem Physischen Datenverarbeitungssystem die Anwendungsbausteine zugerdnet, die die Regeln vrgeben, mit denen das Physische Datenverarbeitungssystem für die Entgegennahme, Weiterleitung der gezielte Veränderung vn Daten gesteuert wird (vgl. Definitin in E.B.C-1). Bei einem Physischen Datenverarbeitungssystem, dessen Verarbeitung vn Daten mit Sftware gesteuert wird, handelt es sich um Anwendungssysteme, die auf diesem System installiert sind. E.B.E-1.8 Interebenenbeziehung wird für Speicherung benötigt zu Anwendungsbaustein Über die Assziatin wird für Speicherung benötigt werden einem Physischen Datenverarbeitungssystem die Anwendungsbausteine zugerdnet, die die Regeln vrgeben, mit denen das Physische Datenverarbeitungssystem für die Speicherung vn Daten gesteuert wird (vgl. Definitin in E.B.C-1). Bei einem Physischen Datenverarbeitungssystem, dessen Verarbeitung vn Daten mit Sftware gesteuert wird, handelt es sich um Anwendungssysteme, die auf diesem System installiert sind. E.B.E-1.9 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Verweis auf Text Welche und wie viele Rechner verschiedener Klassen (z. B. PC, Server, ) sind in einem Infrmatinssystem im Einsatz? Welche Maßnahmen zur Ausfallsicherheit eines Anwendungssystems sind durch Hardwaremaßnahmen getrffen wrden? Welche Server können sich bei Ausfall gegenseitig ersetzen? Welche virtuellen Server sind vrhanden, aus welchen Physischen Servern werden sie gebildet, den Betrieb welcher Anwendungssysteme ermöglichen sie? Sind Server an unterschiedlichen Standrten installiert, die sich bei Ausfall gegenseitig ersetzen könnten? Welche Gebäude(teile) werden durch welche Teile des Kmmunikatinsnetzes erreicht? Gibt es redundante Netzverbindungen zwischen Gebäude(teile)n? Gibt es einen zentralen, universellen Unternehmensdatenspeicher z. B. durch ein SAN der werden die Daten der Anwendungssysteme (z. B. des PACS) in dedizierten Speichersystemen gespeichert? Gibt es redundante Datenspeicher? E.B.D-1 E.B.E-1.3 E.B.E-3 E.B.E-3 E.B.E-3 E.B.D-1.9 E.B.D

47 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B In welchen Gebäude(teile)n werden Daten auf Papier gelagert? Wie gelangen die Papier-Unterlagen (Akten) drthin? Gibt es drt Möglichkeiten die Akten zu digitalisieren? Welche Zugriffsdmänen besitzt ein Physisches Datenverarbeitungssystem, d. h. welche Anwendungssysteme sind darauf installiert? E.B.E-3, E.B.E-4 E.B.E-3 [16], F.C.A-1.7 E.B.E-1.10 Mdellierungshinweise In dem Mdell eines Gesundheitsinfrmatinssystems, das aus den Infrmatinssystemen mehrerer Krankenhäuser bzw. anderer Versrgungseinrichtungen besteht, können die Physischen Datenverarbeitungssysteme jeder Versrgungseinrichtung auch durch die Kmpsitinsbeziehung zu einem einzigen Physischen Datenverarbeitungssystem je Versrgungseinrichtung zusammengefasst werden (siehe auch [28]). Wegen der Vererbungsregeln wird jedch empfhlen, der s entstehenden Kmpsitin, d. h. dem Physischen Datenverarbeitungssystem, das alle Physischen Datenverarbeitungssysteme der Versrgungseinrichtung zusammenfasst, keine Datenübertragungsverbindungen und keine Interebenenbeziehungen zu Elementen der Lgischen Werkzeugebene zuzurdnen. Das Metamdell kennt keine Unterscheidung in rechnerbasierte der nicht-rechnerbasierte Physische Datenverarbeitungssysteme. Wenn eine slche Unterscheidung in einem Mdell gewünscht wird, können dafür entsprechende Geräteklassen angelegt und den Physischen Datenverarbeitungssystemen zugerdnet werden. Diesen Geräteklassen können dann auch spezifischere Geräteklassen (z. B. PC, Server bzw. Regalanlage, Bte) untergerdnet werden (siehe E.B.E-2.2). Kabel zwischen Physischen Datenverarbeitungssystemen werden in der Regel als Datenübertragungsverbindungen, d. h. als eher passive Kmpnenten eines Kmmunikatinsnetzes mdelliert. Da diese Assziatin auch wieder eine Klasse ist, können bestimmte Eigenschaften dieser Kabelverbindung mdelliert werden. Allerdings können Kabel der Kabelabschnitte bzw. Stecker der Kupplungen auch als eigene Physische Datenverarbeitungssysteme mdelliert werden. Eine Datenübertragungsverbindung zwischen einem Stecker und einem Kabel der zwischen einem Stecker und einer Kupplung müsste dann mdelliert werden, um auszudrücken, dass die beiden Kmpnenten miteinander verbunden sind. Dann darf aber diese Datenübertragungsverbindung nicht physisch, d. h. als weiteres Kabel, sndern nur lgisch in dem Sinne interpretiert werden, dass Daten z. B. vn dem Stecker zu der Kupplung übertragen werden können. E.B.E-2 Geräteklasse E.B.E-2.1 Beschreibung des Knzepts Physische Datenverarbeitungssysteme können über Geräteklassen klassiert werden. Geräteklassen können z. B. sein: Regal, Server, PC, aktive Netzkmpnente, Hub etc. Im 3LGM²-Baukasten können den einzelnen Bausteintypen bestimmte graphische Symble und andere Eigenschaften zugewiesen werden, die vn den zugerdneten Physischen Datenverarbeitungssystemen übernmmen werden können. Geräteklassen werden in den graphischen Darstellungen nicht als eigene Objekte dargestellt. E.B.E-2.2 Spezialisierung vn Geräteklassen E.B.E Knzept Eine Geräteklasse kann durch Untergeräteklassen spezialisiert werden. Eine Geräteklasse kann nur Teilgeräteklasse einer einzigen Gruppengeräteklasse sein. Durch die Spezialisierung können die Geräteklassen und damit auch die zugerdneten Physischen Datenverarbeitungssysteme z. B. in rechnerbasierte und nicht-rechnerbasierte eingeteilt werden. E.B.E Vererbung Die Untergeräteklassen einer Geräteklasse erben vn dieser Geräteklasse keine Eigenschaften der Beziehungen! 45

48 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.E Ausblenden und Vergröbern Bei dem Vergröbern einer Geräteklasse werden die Untergeräteklassen (vrübergehend) aus dem Mdell entfernt. Die Assziatinen der Untergeräteklassen zu Physischen Datenverarbeitungssystemen werden der Gruppengeräteklasse zugerdnet, deren Spezialisierung sie sind. Die anderen Assziatinen verschwinden für den Zeitraum der Vergröberung. E.B.E-2.3 Beziehung spezifiziert zu Physischem Datenverarbeitungssystem Jeder Geräteklasse können beliebig viele Physische Datenverarbeitungssysteme zugerdnet werden. E.B.E-2.4 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Verweis auf Text Welche und wie viele Geräte einer bestimmten Geräteklasse werden in einem Infrmatinssystem eingesetzt? Wie viele PCs, wie viele Server sind vrhanden? E.B.E-2.5 Mdellierungshinweise Umfang und Granularität der mdellierten Geräteklassen rientieren sich klar am Mdellierungszweck. Wenn die mdellierten Geräteklassen zum Vergleich zwischen Infrmatinssystemen verwendet werden sllen, ist sicherzustellen, dass in den entsprechenden Mdellen dieselben Geräteklassen verwendet werden. E.B.E-3 Standrt E.B.E-3.1 Beschreibung des Knzepts Ein Standrt ist eine gegraphische Psitin, ein Gebäude der Gebäudeteil, ein bestimmter Raum der eine anders zu beschreibende Psitin im Raum. S ist z. B. der Operatinssaal O3 in der 4. Etage des Gebäudes Paracelsusstraße 17 ein Standrt. Dieses Knzept darf nicht mit dem Knzept der Organisatinseinheit verwechselt werden. Wenn z. B. CH1O1 und NCHO1 die perativen Bereiche der Chirurgischen Klinik 1 und der Neurchirurgischen Klinik als Organisatinseinheit bezeichnen, können sich beide Organisatinseinheiten durchaus denselben Operatinssaal O3 als Standrt teilen. E.B.E-3.2 Zerlegung vn Standrten E.B.E Knzept Ein Standrt kann durch Zerlegung in Teilstandrte zerlegt werden. Ein Standrt kann nur Teilstandrt eines einzigen Standrts sein. E.B.E Vererbung Die Teilstandrte eines Standrts erben vn diesem Standrt keine Eigenschaften der Beziehungen! E.B.E Vergröbern Bei dem Vergröbern der Teilstandrte eines Standrts werden die Teilstandrte (vrübergehend) aus dem Mdell entfernt. Dies bedeutet, dass auf die differenzierte Betrachtung, die durch die Teilstandrte gegeben ist, verzichtet wird. Die Assziatinen der Teilstandrte zu Physischen Datenverarbeitungssystemen werden dem Standrt zugerdnet, dessen Teil sie sind. Die anderen Assziatinen verschwinden mit der Vergröberung. E.B.E-3.3 Beziehung beherbergt zu Physischem Datenverarbeitungssystem Wenn sich ein Physisches Datenverarbeitungssystem dauerhaft an einem bestimmten Ort befindet, kann ihm dieser Ort als Standrt zugewiesen werden. Insbesndere mbilen Geräten wie Tablet-PC der PDA wird man möglicherweise keinen Standrt zuweisen. Die Beziehung wird graphisch nicht dargestellt. 46

49 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B E.B.E-3.4 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Verweis auf Text Welche Teile des Krankenhauses werden durch das Kmmunikatinsnetz erreicht? Welche Anwendungssysteme werden möglicherweise nicht mehr funktinieren, wenn es zu einem Grßfeuer in einem bestimmten Gebäude kmmt. Welche Aufgaben können im Arztzimmer auf der 3. Etage des Asklepisweg 3 mit Rechnerunterstützung durchgeführt werden? E.B.B-2, E.B.E-1 E.B.B-2, E.B.E-1 E.B.D-1, E.B.D-1, E.B.E-3.5 Mdellierungshinweise Umfang und Granularität der mdellierten Standrte rientieren sich klar am Mdellierungszweck. E.B.E-4 Datenübertragungsverbindung E.B.E-4.1 Beschreibung des Knzepts Zwischen zwei Physischen Datenverarbeitungssystemen können Daten über eine Datenübertragungsverbindung transprtiert werden. Eine gerdnete Flge vn Physischen Datenverarbeitungssystemen, die jeweils durch eine Datenübertragungsverbindung verbunden sind und daher nacheinander durchlaufen werden können, wird als Datenübertragungsstrecke bezeichnet. Grundsätzlich wird darauf verzichtet, bei den Datenübertragungsverbindungen zu beschreiben, welche Arten vn Daten und damit auch, welche Objekttypen drt transprtiert werden können. Es wird vielmehr davn ausgegangen, dass dann, wenn eine Datenübertragungsverbindung besteht, drt grundsätzlich alle Daten transprtiert werden können. Allerdings kann differenziert werden, mit welchen Trägern (siehe E.B.E-4.3) die Übertragung der Daten erflgen kann. E.B.E-4.2 Beziehung zu Physischem Datenverarbeitungssystem ( überträgt Daten zu, empfängt Daten vn ) Eine Datenübertragungsverbindung verbindet genau zwei Physische Datenverarbeitungssysteme. Die Verbindung ist eine gerichtete Beziehung, d. h. das Daten vn einem bestimmten Physischen Datenverarbeitungssystem zu einem anderen bestimmten Physischen Datenverarbeitungssystem transprtiert werden können. Datenübertragungsverbindungen können swhl einseitig als auch beidseitig gerichtet sein. Zwischen zwei Physischen Datenverarbeitungssystemen können mehrere Datenübertragungsverbindungen mdelliert werden. E.B.E-4.3 Beziehung überträgt zu Übertragungsmedium Eine Datenübertragungsverbindung lässt sich durch die Zurdnung vn Übertragungsmedien im Hinblick auf die Art der Datenübertragung näher beschreiben. Eine Datenübertragungsverbindung kann über beliebig viele Übertragungsmedien übertragen. Ein Übertragungsmedium kann signalbasiert der nicht signalbasiert sein (blean-wert). Daraus ergibt sich, dass eine Datenübertragungsverbindung gleichzeitig als signalbasiert und auch als nicht signalbasiert gekennzeichnet sein kann. E.B.E-4.4 Fragen des Infrmatinsmanagements und Unterstützung durch den 3LGM²-Baukasten Fragen des Infrmatinsmanagements Müssen zwischen zwei bestimmten Physischen Datenverarbeitungssystemen die Daten physisch transprtiert werden (z. B. auf Disketten der auf Papier) der werden die Daten autmatisch und hne Eingreifen durch eine Transprtpersn durch eine Signalübertragung übermittelt? Erflgt die Signalübertragung über ein Kabel der drahtls, z. B. mit Bluetth der WLAN? Verweis auf Text E.B.E-1 E.B.E-5 Zwischen welchen Physischen Datenverarbeitungssystemen werden die Daten physisch transprtiert (z. B. E.B.E-1 47

50 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B auf Disketten der auf Papier) und w werden die Daten autmatisch und hne Eingreifen durch eine Transprtpersn durch eine Signalübertragung übermittelt? Welche (Gruppen vn) Physischen Datenverarbeitungssysteme(n) können keine Daten mit anderen Physischen Datenverarbeitungssystemen austauschen? In welcher Frm erflgt die Anbindung des Intranets der Organisatin mit dem Internet? Welche Kmmunikatin zwischen Anwendungssystemen wird unterbrchen, wenn eine bestimmte Datenübertragungsverbindung ausfällt? Auf welche Datenübertragungsverbindungen ist die Erledigung einer bestimmten Aufgabe angewiesen (damit die erfrderlichen Daten vrhanden und die erzeugten Daten gespeichert werden können)? E.B.E-1 E.B.E-4 E.B.D-1 E.B.D-1, E.B.E-1 E.B.E-4.5 Mdellierungshinweise Eine Datenübertragungsverbindung ist auch zwischen rechnerbasierten Physischen Datenverarbeitungssystemen nicht ntwendigerweise ein Kabel und umgekehrt. Die Datenübertragungsverbindung drückt vielmehr lediglich aus, dass zwischen den beiden Systemen Daten fließen können. Möglicherweise erflgt dies wie z. B. bei Stecker und Kupplung über einen unmittelbaren Kntakt, sdass es in einem slchen Fall für die Datenübertragungsverbindung keine physische Entsprechung gibt. (vgl. E.B.E-1.10) E.B.E-5 Übertragungsmedium E.B.E-5.1 Beschreibung des Knzepts Ein Übertragungsmedium beschreibt, auf welche Art Daten auf einer Datenübertragungsverbindung übermittelt werden können. Beispielsweise kann die Datenübertragung mit Papier, CD, Kabel der per Funk erflgen. Grundsätzlich lassen sich Daten mit nicht-gegenständlichen Signalen der mit gegenständlichen Übertragungsmedien übertragen. Ein Übertragungsmedium kann smit signalbasiert der nicht signalbasiert sein (blean-wert), d. h. auch beides gleichzeitig ist möglich. Übertragungsmedien mit nicht-gegenständlichen Signalen sind z. B. metallener Kntakt, Kupferkabel verschiedener Spezifikatinen, Lichtwellenleiter, WLAN, Bluetth usw. Ein gegenständliches Übertragungsmedium ist ein transprtables physisches Medium, auf dem Daten für kurze der lange Zeit ihren physischen Ausdruck finden. Dazu gehören z. B. Papierbgen, Film, Karteikarte, Diskette, Chipkarte, CD, Memry Stick usw. E.B.E-5.2 Beziehung wird genutzt vn zu Datenübertragungsverbindung Jedes Übertragungsmedium kann beliebig vielen Datenübertragungsverbindungen zugerdnet werden und beschreibt dann, auf welche Weise die Datenübertragung an dieser Stelle erflgen kann. E.B.E-5.3 Fragen des Infrmatinsmanagements und Unterstützung durch den 3LGM²-Baukasten Siehe bei Datenübertragungsverbindungen E.B.E-4.4 E.B.E-5.4 Mdellierungshinweise In den meisten Fällen werden nur Cmputer der ähnliche sftwaregesteuerte Physische Datenverarbeitungssysteme durch Datenübertragungsverbindungen für nicht-gegenständliche Signale verbunden sein. Denkbar ist aber auch, dass zwischen dem Inventar eines Archivs und dem einer Statin Daten über ein Faxgerät übertragen werden. Dieses Faxgerät würde das gegenständliche Papier in Signale knvertieren bzw. umgekehrt. S wäre zu erklären, dass zwischen den beiden persnengesteuerten Physischen Datenverarbeitungssystemen, die das jeweilige Inventar repräsentieren, Signale und nicht gegenständliches Papier ausgetauscht wird. Für das Infrmatinsmanagement wird es in vielen Fällen ausreichen, wenn man bei einer Auswertung alle slchen Knvertierungspunkte auf einer Datenübertragungsstrecke identifizieren kann, hne die knvertierenden Physischen Datenverarbeitungssysteme im Einzelfall erkennen zu können. Für Übertragungs- und Netzwerkprtklle sind im 3LGM² keine expliziten Klassen vrgesehen. Sie können jedch durch eine entsprechende Ausdifferenzierung der auf Signalen basierenden Übertragungsmedien dargestellt werden. 48

51 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Als gegenständlicher Datenträger kann z. B. der Transprtdienst der Zivildienstleistenden aufgefasst werden. Diese bewegen dann z. B. beschriebenes Papier, belichtete Filme, CDs, Disketten, Bänder u.ä. und transprtieren auf diese Weise die auf den Datenträgern abgelegten Daten. Gegenständliche Datenträger werden vrrangig bei der Datenübertragung zwischen persnengesteuerten Physischen Datenverarbeitungssystemen mdelliert, da meist vn einem Eingreifen und einer aktiven Beteiligung vn Menschen auszugehen ist. Allerdings kann die Mdellierung der Datenübertragung mit gegenständlichen Datenträgern auch zwischen sftwaregesteuerten Physischen Datenverarbeitungssystemen sinnvll sein. Für die Zwecke des Infrmatinsmanagements kann in den meisten Fällen darauf verzichtet werden, z. B. das Entnehmen einer CD aus einem PC bzw. das Einlegen der CD in einen PC explizit zu mdellieren. Allerdings ist auch das vllautmatische und sftwaregesteuerte Transprtieren vn CD vn einem sftwaregesteuerten Speicherbaustein zu einem anderen mit Hilfe eines Rbters gelegentlich Realität. E.B.E-6 Beispiel Abbildung 14: Beispiel einer Physischen Werkzeugebene Abbildung 14: zeigt ein Beispiel einer Physischen Werkzeugebene. In diesem Beispiel gibt es sftware- und persnengesteuerte Physische Datenverarbeitungssysteme. Die persnengesteuerten Physischen Datenverarbeitungssysteme sind hellblau unterlegt. Aus dieser Darstellung ergibt sich u.a.: Es gibt einen Transprtdienst, der eine Datenübertragungsverbindung für gegenständliche Dkumententräger vn den Regalanlagen des Zentralarchivs zur Diagnstischen Radilgie realisiert, wbei das Übertragungsmedium Papier ist (symblisiert durch ). Ebenfalls auf Papier können Daten vn den Regalanlagen des Zentralarchivs zu den persnengesteuerten Physischen Datenverarbeitungssystemen in der Chirurgischen Klinik und Pliklinik transprtiert werden. 49

52 E.B Die Basis des Drei-Ebenen-Metamdells: 3LGM²-B Zu den physischen Werkzeugen der Chirurgischen Klinik und Pliklinik II (CHII) zählt auch der Arbeitsplatzrechner PC11. Er ist über eine Datenübertragungsverbindung für nicht-gegenständliche Signale, die durch Kabel realisiert ist (Datenübertragungsverbindungen dieses Übertragungsmediums sind in diesem Beispiel nicht näher mit einem Symbl gekennzeichnet), mit einem Switch des Kmmunikatinsnetzes verbunden. Über eine Datenübertragungsverbindung für gegenständliche Dkumententräger auf der Basis vn Papier ist er mit den persnengesteuerten physischen Werkzeugen der CHII verbunden. Dies bedeutet, dass eine Persn die Daten vn dem Dkumententräger abliest und in den Arbeitsplatzrechner eingibt. Dieser Arbeitsplatzrechner ist aber auch mit dem Arbeitsplatzrechner PC5 verbunden. Hier werden Disketten transprtiert, die vn Persnen in das entsprechende Laufwerk eingelegt bzw. drt entnmmen werden. Der Tablet-PC vn Sr. Uta ist über eine drahtlse Datenübertragungsverbindung für nicht-gegenständliche Signale mit dem Kmmunikatinsnetz verbunden ( ). Die hierfür erfrderlichen Sende- und Empfangsgeräte sind nicht mdelliert wrden. Für eine größere Anzahl vn Arbeitsplatzrechnern ist nicht mdelliert wrden, in welcher Frm sie mit anderen Physischen Datenverarbeitungssystemen verbunden sind. Wenn tatsächlich keine Datenübertragungsverbindungen für nicht-gegenständliche Signale z. B. mit dem Kmmunikatinsnetz existieren, s wird es wahrscheinlich dch Verbindungen mit persnengesteuerten Physischen Datenverarbeitungssystemen geben. Das Mdell sllte daher entsprechend kmplettiert werden. 50

53 E.C Erweiterungen des Metamdells bzw. Mdifikatinen des Metamdells E.C Erweiterungen des Metamdells bzw. Mdifikatinen des Metamdells E.C.A Nachrichtenrientierte Kmmunikatin mit Nachrichtentypen: 3LGM²-M E.C.A-1 Überblick Das Basis-Metamdell 3LGM²-B kennt weder Nachrichtentypen nch Kmmunikatinsstandards, sndern beschreibt die Kmmunikatin zwischen Anwendungsbausteinen unmittelbar durch die Angabe der Objekttypen, zu denen Daten bzw. Nachrichten über die Kmmunikatinsverbindungen gesendet werden. Wenn in einem Mdell die Kmmunikatin genauer beschrieben und z. B. dargestellt werden sll, dass die Kmmunikatin zwischen bestimmten Anwendungsbausteinen auf der Basis vn HL7, zwischen anderen auf der Basis vn DICOM und an anderen Stellen möglicherweise mit prprietären Nachrichtentypen (Message Types) erflgt, dann kann die Erweiterung 3LGM²-M verwendet werden. 3LGM²-M entsteht aus 3LGM²-B im Wesentlichen durch die Hinzunahme der Klassen Nachrichtentyp und Kmmunikatinsstandard. In den Abschnitten E.C.A-2 bis E.C.A-7 werden diese Klassen und weitere damit verbundene Ergänzungen erläutert. In Abschnitt E.C.A-8 wird erläutert, wie ein 3LGM²-B-Mdell in ein 3LGM²-M- Mdell knvertiert werden kann und umgekehrt. 3LGM²-M ist in Abbildung 15 in UML-Ntatin dargestellt. 51

54 E.C.A Nachrichtenrientierte Kmmunikatin mit Nachrichtentypen: 3LGM²-M Abbildung 15: Das Metamdell 3LGM²-M 52

55 E.C.A Nachrichtenrientierte Kmmunikatin mit Nachrichtentypen: 3LGM²-M E.C.A-2 Nachrichtentyp E.C.A-2.1 Beschreibung des Knzepts Eine Nachricht (Message) ist eine Menge vn Daten, die zum Zwecke der Kmmunikatin zwischen Anwendungsbausteinen zusammengestellt wurde und als Einheit betrachtet und kmmuniziert wird. Ein Nachrichtentyp beschreibt eine Klasse gleichartiger Nachrichten und legt fest, Daten welcher Objekttypen bei einer Nachricht des Nachrichtentyps transprtiert werden. Die Anwendungsbausteine können durchaus Organisatinssysteme sein und die Kmmunikatin muss nicht ntwendigerweise elektrnisch und digital erflgen. Nachrichtentypen sind demzuflge z. B. Aufnahmebgen, Labrbefund, Arztbrief der ADT Message und ORU Observatinal Results (Unslicited) aus dem Kmmunikatinsstandard HL7 V2.3. E.C.A-2.2 Beziehung gehört zu zu Kmmunikatinsstandard Jeder Nachrichtentyp gehört zu einem Kmmunikatinsstandard; s können Nachrichtentypen gruppiert werden. Gehören Nachrichtentypen nicht zu einem der bekannten Kmmunikatinsstandards wie HL7 der DICOM der sind sie gar völlig prprietär, kann z. B. der Kmmunikatinsstandard prprietäre Nachrichtentypen des Krankenhauses A angelegt und zugerdnet werden. E.C.A-2.3 Beziehung zu wird übertragen vn zu Kmmunikatinsverbindung, kann gesendet werden vn und kann empfangen werden vn zu Sende- und Empfangsschnittstelle Die Kmmunikatinsschnittstellen eines Anwendungsbausteins ermöglichen es dem Anwendungsbaustein, Nachrichten bestimmter Nachrichtentypen zu versenden bzw. zu empfangen. Besteht zwischen einer Empfangs- und einer Sendeschnittstelle eine Kmmunikatinsverbindung, dann kann mdelliert werden, zu welchen Nachrichtentypen tatsächlich Nachrichten zwischen den beiden Kmmunikatinsschnittstellen kmmuniziert werden. E.C.A-2.4 Interebenenbeziehung kmmuniziert zu Objekttyp Die in einem Nachrichtentyp zusammengestellten Daten repräsentieren Infrmatinen über Objekte, die durch Objekttypen beschrieben sind. Ein Nachrichtentyp stellt daher in der Regel Daten mehrerer Objekte zusammen, d. h. er kmmuniziert mehrere Objekttypen. Beispielsweise kmmuniziert der Nachrichtentyp ADT Message swhl den Objekttyp Patient als auch den Objekttyp Behandlungsfall (siehe Abbildung 6). E.C.A-2.5 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Daten zu welchen Objekttypen werden vn Nachrichten eines bestimmten Nachrichtentyps transprtiert? Zu welchen Objekttypen werden zwischen zwei bestimmten Anwendungsbausteinen Nachrichten ausgetauscht? Welchen Teil eines bestimmten Kmmunikatinsstandards (z. B. HL7) unterstützt eine bestimmte Kmmunikatinsschnittstelle? Nachrichten welcher Nachrichtentypen kann sie senden/empfangen? Wie uneinheitlich und kmplex ist die Kmmunikatin? Mit wie vielen und welchen Nachrichtentypen wird ein bestimmter Objekttyp versendet? Verweis auf Text E.C.A-4 E.C.A-4 E.C.A-3 E.C.A-4 E.C.A-2.6 Mdellierungshinweise Im Wesentlichen ist ein Nachrichtentyp eine Menge vn Objekttypen; nämlich die Menge der Objekttypen, deren Daten bei einer Nachricht des betreffenden Nachrichtentyps versendet werden. Es kann aber sinnvll sein, für ein und dieselbe Menge vn Objekttypen auch unterschiedliche Nachrichtentypen zu mdellieren. Damit kann ausgedrückt werden, dass zwar Daten zu Objekten derselben Objekttypen transprtiert werden, dies aber z. B. auf Grund unterschiedlicher Kmmunikatinsstandards in unterschiedlicher Art und Weise geschieht. Zusammenfassungen vn Daten werden in vielen Kntexten auch als Dkumente bezeichnet, Klassen slcher Dkumente als Dkumentenarten der typen. Im Krankenhaus sind z. B. Aufnahmebgen, Labrbefund der Arztbrief slche Dkumententypen. Bei der Verwendung des Begriffs Dkument bzw. Dkumententyp wird 53

56 E.C.A Nachrichtenrientierte Kmmunikatin mit Nachrichtentypen: 3LGM²-M häufig impliziert, dass diese Zusammenfassungen vn Daten auf Papier als Träger erflgen. Auch slche Dkumentenarten bzw. typen werden in 3LGM² als Nachrichtentypen mdelliert. Bei Bedarf können slche Nachrichtentypen z. B. einem Kmmunikatinsstandard Dkumententypen des Krankenhauses A zugerdnet werden. In einem 3LGM²-Mdell werden (Zusammenfassungen vn) Daten auf der Lgischen Werkzeugebene nur dann explizit mdelliert, nämlich als Nachrichtentyp, wenn sie zwischen Anwendungsbausteinen kmmuniziert werden. Dies ergibt sich aus dem Ziel, darzustellen, aus welchen Bausteinen, d. h. Anwendungsbausteinen, sich das gesamte Infrmatinssystem zusammensetzt, nicht aber, wie diese Anwendungsbausteine intern aufgebaut sind. Entsprechend wird auch ein Dkumententyp nur dann als Nachrichtentyp mdelliert, wenn er zwischen unterschiedlichen Anwendungsbausteinen kmmuniziert wird. Auf die Mdellierung vn Dkumententypen, die lediglich innerhalb eines Anwendungsbausteins relevant sind, wird verzichtet und kann verzichtet werden. Vgl. hierzu auch E.B.D-1.2. E.C.A-3 Kmmunikatinsstandard E.C.A-3.1 Knzept Ein Kmmunikatinsstandard beschreibt im Allgemeinen, mit welchem Datenfrmat zu welchen Ereignissen Nachrichten übertragen werden. In 3LGM²-M beschränkt sich das Knzept auf die Beschreibung der Frmate durch Verweis auf entsprechende Nachrichtentypen und verzichtet auf die Mdellierung vn Ereignissen. Ein Kmmunikatinsstandard fasst als im 3LGM²-M mehrere Nachrichtentypen zu einer bestimmten Gruppe zusammen. Kmmunikatinsstandards sind z. B. HL7 der DICOM. Nachrichtentypen, die ein Hersteller prprietär für ein bestimmtes Sftwareprdukt definiert hat, können z. B. mit dem Kmmunikatinsstandard prprietäre Nachrichtentypen des Herstellers A angelegt und zusammengefasst werden. E.C.A-3.2 Beziehung enthält zu Nachrichtentyp Einem Kmmunikatinsstandard können beliebig viele Nachrichtentypen zugerdnet werden. E.C.A Fragen des Infrmatinsmanagements Fragen des Infrmatinsmanagements Verweis auf Text Welche Kmmunikatinsstandards werden in dem Infrmatinssystem verwendet? Vn welchen Anwendungssystemen wird ein bestimmter Kmmunikatinsstandard verwendet? Wie uneinheitlich und kmplex ist die Kmmunikatin? Mit wie vielen und welchen Kmmunikatinsstandards wird ein bestimmter Objekttyp versendet? E.C.A-5 E.C.A-4 E.C.A-4 Objekttyp Dieses Knzept ist in Abschnitt E.B.B-1 bereits detailliert beschrieben. Für die Erweiterung 3LGM²-M sind jedch die flgenden Ergänzungen (bei kleineren Ergänzungen fett markiert) erfrderlich. E.C.A-4.1 Zerlegung und Spezialisierung E.C.A Vererbung Wie in E.B.B beschrieben, drückt eine Vererbung bei Objekttypen aus, dass alle Eigenschaften des Gruppenbjekttyps auch für die Objekttypen als gegeben angesehen werden sllen, die Bestandteile dieses Gruppenbjekttyps sind. Alle Eigenschaften und Assziatinen, die dem Gruppenbjekttyp zugewiesen werden, werden auch für die Unterbjekttypen als gegeben angesehen, d. h. die Eigenschaften und Assziatinen werden vererbt. Dies bedeutet, dass alle Beziehungen zu Aufgaben, Anwendungsbausteinen und zu Nachrichtentypen, die für den Gruppenbjekttyp mdelliert sind, auch als für alle seine Unterbjekttypen mdelliert gelten, als vererbt werden. E.C.A Vergröbern Bei dem Vergröbern eines Gruppenbjekttyps werden seine Unterbjekttypen (vrübergehend) aus dem Mdell entfernt. Dies bedeutet, dass auf die differenzierte Betrachtung, die durch die Unterbjekttypen gegeben ist, verzichtet 54

57 E.C.A Nachrichtenrientierte Kmmunikatin mit Nachrichtentypen: 3LGM²-M wird. Die Assziatinen der Unterbjekttypen zu Aufgaben, Anwendungsbausteinen und Nachrichtentypen werden dann für die Dauer der Vergröberung vllständig dem Gruppenbjekttyp zugerdnet. E.C.A-4.2 Interebenenbeziehung wird kmmuniziert in zu Nachrichtentyp Werden die Daten über Objekte, auf die ein bestimmter Objekttyp verweist, in mehreren Anwendungsbausteinen gespeichert, dann müssen diese Daten zwischen diesen Anwendungsbausteinen auch ausgetauscht, d. h. kmmuniziert werden. Darüber hinaus werden die Daten ggf. auch in Anwendungsbausteinen benötigt, in denen sie nicht gespeichert werden. Dies kann z. B. dann der Fall sein, wenn ein slcher Anwendungsbaustein eine Aufgabe unterstützt, die den auf die Daten verweisenden Objekttyp interpretiert. Zwischen den Anwendungsbausteinen werden die Daten, auf die ein bestimmter Objekttyp verweist, mit Nachrichten kmmuniziert. Die Assziatin eines Objekttyps zu einem der mehreren Nachrichtentypen drückt aus, dass Nachrichten dieser Nachrichtentypen Daten über Objekte, auf die der Objekttyp verweist, kmmuniziert. Kurz: der Objekttyp wird durch die Nachrichtentypen kmmuniziert. E.C.A-5 Anwendungsbaustein Dieses Knzept ist in Abschnitt E.B.D-1 bereits detailliert beschrieben. Für die Erweiterung 3LGM²-M sind jedch flgende Ergänzungen erfrderlich: E.C.A-5.1 Mdellierungshinweise E.C.A-6 Kmmunikatinsverbindungen zwischen Anwendungssystemen und Organisatinssystemen: Wenn Nachrichten vn einem Organisatinssystem an ein Anwendungssystem gesendet werden bedeutet dies, das Daten, die auf nicht-rechnerbasierten Medien vrliegen, vn Menschen in ein rechnerbasiertes Anwendungssystem eingegeben werden. Dies ist zum Beispiel dann der Fall, wenn ein auf Papier vrhandenes Dkument eingetippt, ein (aufgezeichnetes) Diktat geschrieben der eine CD vn Hand in ein Lesegerät eingelegt wird, damit die darauf enthaltenen Daten vn dem Anwendungssystem gelesen werden können. Umgekehrt bedeutet das Senden vn Nachrichten vn einem Anwendungssystem an ein Organisatinssystem, dass Daten, die in einem rechnerbasiertem Anwendungssystem gespeichert sind, Menschen in einer nichtrechnerbasierten Umgebung zur Verfügung gestellt werden. Dies ist zum Beispiel dann der Fall, wenn Daten auf dem Bildschirm angezeigt, auf dem Drucker ausgedruckt, in Frm akustischer Signale abgehört (Musik, Text) der auf einer DVD gespeichert werden und diese Daten anschließend vn Menschen innerhalb des Organisatinssystems weiterverarbeitet werden. In diesem Fall sllte weder ein Nachrichtentyp zur Mdellierung verwendet werden, der angibt, die Nachricht wäre (bereits der nch) in der digitalen Frm, in der die in ihr enthaltenen Daten in dem Anwendungssystem gespeichert werden, nch ein Nachrichtentyp verwendet werden, der angibt, die Nachricht wäre (bereits der nch) in der Frm, in der die in ihr enthaltenen Daten in dem Organisatinssystem gespeichert werden. Es empfiehlt sich vielmehr, zunächst einen Kmmunikatinsstandard zu mdellieren, der Ein- bzw. Ausgaben in Anwendungssysteme beschreibt (z. B. Eingaben in Anwendungssysteme, Ausgaben aus Anwendungssystemen der auch Ein-/Ausgaben in/aus Anwendungssystemen ); es können bei Bedarf auch Kmmunikatinsstandards separat für jedes betrffene Anwendungssystem mdelliert werden (z. B. Eingaben in Anwendungssystem XYZ, Ausgaben aus Anwendungssystem ABC der auch Ein-/Ausgaben in/aus Anwendungssystem EFG ). Diesen Kmmunikatinsstandards sllten dann Nachrichtentypen zugerdnet werden, die entweder recht grb beschreiben, dass eine bestimmte Menge vn Objekttypen ein- bzw. ausgegeben werden der aber auch detaillierter beschreiben, in welcher Frm das erflgt (z. B. Bildschirmeingabe vn Patientenstamm- und Patientenfalldaten, Audiwiedergabe eines Befunddiktats, Ein-/Ausgabe ). Kmmunikatinsverbindung, Sende- und Empfangsschnittstelle Dieses Knzept ist in Abschnitt E.B.D-3 bereits detailliert beschrieben. Für die Erweiterung 3LGM²-M sind jedch flgende Ergänzungen erfrderlich: E.C.A-6.1 Interebenenbeziehungen überträgt vn Kmmunikatinsverbindung zu Nachrichtentyp, kann senden und kann empfangen vn Sende- bzw. Empfangsschnittstelle zu Nachrichtentyp Die Assziatin einer Sendeschnittstelle zu einem Nachrichtentyp beschreibt, dass diese Sendeschnittstelle Nachrichten dieses Typs versenden kann. Vereinfachend kann davn gesprchen werden, dass die Sendeschnittstelle den Nachrichtentyp versenden kann. 55

58 E.C.A Nachrichtenrientierte Kmmunikatin mit Nachrichtentypen: 3LGM²-M Die Assziatin einer Empfangsschnittstelle zu einem Nachrichtentyp beschreibt, dass diese Empfangsschnittstelle Nachrichten dieses Typs empfangen kann. Vereinfachend kann davn gesprchen werden, dass die Empfangsschnittstelle den Nachrichtentyp empfangen kann. Die Assziatin einer Kmmunikatinsverbindung zu einem Nachrichtentyp beschreibt, dass diese Kmmunikatinsverbindung Nachrichten dieses Typs transprtiert. Vereinfachend kann davn gesprchen werden, dass die Kmmunikatinsverbindung den Nachrichtentyp transprtiert. E.C.A-6.2 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Welche Möglichkeiten zum Senden und Empfangen vn Nachrichten hat ein Anwendungsbaustein? Welche Kmmunikatinsstandards und welche darin enthaltenen Nachrichtentypen unterstützt eine Kmmunikatinsschnittstelle? Unterstützt eine Empfangsschnittstelle eines bestimmten Anwendungssystems, die einige HL7-Nachrichten empfangen kann, als ffenbar HL7-fähig ist, auch den Empfang des Nachrichtentyps ORU Observatinal Results (Unslicited)? Verweis auf Text E.B.D-1 E.C.A-2, E.C.A-3 E.B.D-1 E.C.A-6.3 Mdellierungshinweise E.C.A-7 Bei einem Anwendungsbaustein kann für jeden Nachrichtentyp, zu dem er Nachrichten versenden/empfangen kann, eine besndere Kmmunikatinsschnittstelle mdelliert werden. Es kann auch für alle sendbaren Nachrichtentypen eine einzige Sende- und für alle empfangbaren Nachrichtentypen eine einzige Empfangsschnittstelle mdelliert werden. Es empfiehlt sich aber, auch Kmmunikatinsschnittstellen im Sinne vn Assets (vgl. E.B.D-1.11) zu mdellieren, d. h. dann eine Kmmunikatinsschnittstelle zu mdellieren, wenn diese in der mdellierten Frm vn dem jeweiligen Hersteller s hergestellt bzw. geliefert und vn der einsetzenden Organisatin bei Kauf bzw. Betrieb zu bezahlen ist. Datenübertragungsverbindung Dieses Knzept ist in Abschnitt E.B.E-4 bereits detailliert beschrieben. Für die Erweiterung 3LGM²-M ist jedch flgende Ergänzung erfrderlich: Grundsätzlich wird darauf verzichtet, bei den Datenübertragungsverbindungen zu beschreiben, welche Nachrichtentypen drt transprtiert werden können. Es wird vielmehr davn ausgegangen, dass dann, wenn eine Datenübertragungsverbindung besteht, drt grundsätzlich alle Nachrichtentypen transprtiert werden können. E.C.A-8 Knvertierung vn Mdellen zwischen 3LGM²-B und 3LGM²-M Der 3LGM²-Baukasten unterstützt die Knvertierung vn Mdellen zwischen 3LGM²-B und 3LGM²-M. E.C.A-8.1 Knvertierung vn 3LGM²-B nach 3LGM²-M Die Knvertierung ist verlustls. Für jeden Objekttyp, der eine Beziehung zu einer Kmmunikatinsverbindung, Sende- der Empfangsschnittstelle hat, wird ein Nachrichtentyp mit der Bezeichnung des Objekttyps generiert. Der Nachrichtentyp erhält eine Beziehung zu dem Objekttyp und die entsprechende Beziehung zu einer Kmmunikatinsverbindung, Sende- bzw. Empfangsschnittstelle. Alle generierten Nachrichtentypen werden einem ebenfalls generierten Kmmunikatinsstandard generierte Nachrichtentypen zugerdnet. E.C.A-8.2 Knvertierung vn 3LGM²-M nach 3LGM²-B Die Knvertierung ist nicht verlustls und lässt sich nicht rückgängig machen. Alle Kmmunikatinsstandards werden entfernt. Für jeden Nachrichtentyp, der eine Beziehung zu einer Kmmunikatinsverbindung, Sende- bzw. Empfangsschnittstelle hat, werden die Objekttypen, zu denen er in Beziehung steht, unmittelbar der jeweiligen Kmmunikatinsverbindung, Sende- bzw. Empfangsschnittstelle zugerdnet. Schließlich werden alle Nachrichtentypen entfernt. 56

59 E.C.B Servicerientierte Kmmunikatin: 3LGM²-S E.C.B Servicerientierte Kmmunikatin: 3LGM²-S E.C.B-1 Überblick Swhl das Basis-Metamdell 3LGM²-B als auch die Erweiterung für nachrichtenrientierte Kmmunikatin 3LGM²- M gehen vm Paradigma des Austauschs vn Daten als Mittel zur Integratin aus. Mit diesem Mittel ist eine Datenintegratin gut, eine funktinale Integratin jedch nur sehr umständlich zu realisieren. Zunehmend gewinnen aber Architekturen vn Infrmatinssystemen auch in der Praxis an Bedeutung, bei denen die einzelnen Anwendungsbausteine sich wechselseitig Services (Dienste) zur Verfügung stellen bzw. diese wechselseitig nutzen können, z. B. Servicerientierte Architekturen (SOA) [29-32]. In der Metamdell-Erweiterung 3LGM²-S für die servicerientierte (diensterientierte) Kmmunikatin werden daher Klassen angebten, mit denen Services, ihre Bereitstellung und ihre Nutzung mdelliert werden können. 3LGM²-S basiert auf [16]. Nur Mdelle auf der Basis vn 3LGM²-M, d. h. Mdelle in denen bereits Nachrichtentypen mdelliert wurden, können autmatisch zu 3LGM²-S-Mdellen erweitert werden. Umgekehrt ist eine Rück-Knvertierung nicht mehr möglich. Mdelle auf der Basis vn 3LGM²-S entstehen aus Mdellen auf der Basis vn 3LGM²-M im Wesentlichen durch die Beschreibung des Sendens vn Nachrichten als Nutzung eines Empfangsdienstes beim Empfänger; die gesendeten Daten werden als Parameter dieses Empfangsdienstes aufgefasst (siehe E.C.B-12.1). Mdelle auf der Basis vn 3LGM²-B können manuell zu 3LGM²-S-Mdellen erweitert werden. Umgekehrt können Mdelle auf der Basis vn 3LGM²-S autmatisch zu 3LGM²-M und 3LGM²-B-Mdellen reduziert werden. 3LGM²-M ist in Abbildung 16 in UML-Ntatin dargestellt. 57

60 E.C.B Servicerientierte Kmmunikatin: 3LGM²-S Abbildung 16: Das Metamdell 3LGM²-S 58

61 E.C.B Servicerientierte Kmmunikatin: 3LGM²-S E.C.B-2 Klassen in 3LGM²-M, die durch andere Klassen ersetzt werden Flgende Knzepte (Klassen) in 3LGM²-M entfallen in 3LGM²-S bzw. werden durch andere Knzepte ersetzt: Sendeschnittstelle wird ersetzt durch aufrufende Schnittstelle (siehe E.C.B-6); Empfangsschnittstelle wird ersetzt durch bereitstellende Schnittstelle(siehe E.C.B-5); Nachrichtentyp entfällt; Kmmunikatinsstandard entfällt, kann aber durch Serviceklasse (siehe E.C.B-4) ersetzt werden. In den flgenden Abschnitten werden die neuen Knzepte und Beziehungen und die Knzepte beschrieben, die eine angepasste Bedeutung erhalten. E.C.B-3 Service E.C.B-3.1 Beschreibung des Knzepts Ein Anwendungsbaustein implementiert bestimmte Funktinalitäten, mit deren Hilfe er die Erledigung vn Aufgaben unterstützt. Definitin: Service Ein Service ist eine Funktinalität, die ein Anwendungsbaustein s bereitstellt, dass sie vn anderen Anwendungsbausteinen genutzt werden kann. Services werden auch als (Remte) Functin der (Remte) Prcedure bezeichnet. Die Ausführung eines Services durch den bereitstellenden Anwendungsbaustein hat eine der mehrere der flgenden Auswirkungen: Daten, die der Anwendungsbaustein verwaltet, werden verändert; es werden Interaktinen mit einem Nutzer des Anwendungsbausteins ausgeführt; es werden Services aufgerufen, die dritte Anwendungsbausteine bereitstellen; es wird ein Ergebnis berechnet, dass dem aufrufenden Anwendungsbaustein zurückübermittelt wird. Einen Service kann ein menschlicher Nutzer des Infrmatinssystems nicht unmittelbar nutzen, um s Unterstützung für die Erledigung einer Aufgabe zu erhalten. Dazu muss der Nutzer vielmehr einen Anwendungsbaustein nutzen, der den Service aufruft. Damit ein Anwendungsbaustein A den Service eines anderen Anwendungsbausteins B nutzen kann, muss A bestimmte Daten als Parameter zur Verfügung stellen und erhält bestimmte Daten als Ergebnis nach Ausführen des Services zurück (siehe E.C.B-3.3). Slche Services können z. B. sein: PAT_AUFNAHME: unter Nutzung dieses Services kann ein beliebiger Anwendungsbaustein die Erledigung der Aufgabe Patientenaufnahme unterstützen, hne die dazu erfrderlichen Funktinalitäten selbst implementieren zu müssen. Zur Nutzung des Services müssen Parameter bereitstellt werden; nach Ausführen des Services wird ein Ergebnis zurückgeliefert. NACHRICHTEN_EMPFANG: Diesem Service kann als Parameter eine Nachricht übergeben werden, die dadurch vn dem Anwendungsbaustein, der den Service bereitstellt, empfangen werden kann. Das Ergebnis könnte eine Acknwledgement-Nachricht sein, die den sendenden Anwendungsbaustein über den erflgreichen Empfang der Nachricht infrmiert. E.C.B-3.2 Beziehung nutzt zu Service Die Beziehung beschreibt, dass ein Service einen anderen Service in Anspruch nehmen kann. Beispielsweise könnte der in E.C.B-3.1 beschriebene Service NACHRICHTEN_EMPFANG vn verschiedenen anderen Services, wie z. B. einem Druckservice der einem Service zum Verteilen vn Dkumenten genutzt werden. 59

62 E.C.B Servicerientierte Kmmunikatin: 3LGM²-S E.C.B-3.3 Interebenenbeziehung realisiert Funktinalität für Erledigung vn zu Aufgabe Für einen Service werden die Aufgaben benannt, für die der Service die entsprechende Funktinalität bereitstellt. Mit Hilfe der s bereitgestellten Funktinalität kann der den Service aufrufende Anwendungsbaustein seine Nutzer bei der Erledigung dieser Aufgaben unterstützen. Auf diese Weise wird beschrieben, wzu der Service durch einen anderen Anwendungsbaustein genutzt werden kann. E.C.B-3.4 Beziehung kann bereitgestellt werden vn zu bereitstellende Schnittstelle Der Service wird vn einem Anwendungsbaustein mit Hilfe der bereitstellenden Schnittstelle s bereitgestellt, dass er vn einem anderen Anwendungsbaustein genutzt werden kann. E.C.B-3.5 Beziehung kann aufgerufen werden vn zu aufrufende Schnittstelle Der Service kann vn einem Anwendungsbaustein mit Hilfe der aufrufenden Schnittstelle genutzt werden. E.C.B-3.6 Beziehung wird aufgerufen über zu Kmmunikatinsverbindung Der Service wird tatsächlich über die Kmmunikatinsverbindung vn den daran beteiligten Anwendungssystemen genutzt. E.C.B-3.7 Beziehung gehört zu zu Serviceklasse Mehrere Services können durch eine Serviceklasse zusammengefasst werden. S können z. B. alle Services, die jeweils gewisse HL7-Nachrichten empfangen können, zu einer Serviceklasse HL7 zusammengefasst werden. E.C.B-3.8 Interebenenbeziehung hat als Parameter zu Objekttyp Damit ein Anwendungsbaustein einen bestimmten Service nutzen kann, müssen ggf. bestimmte Daten vn der aufrufenden Schnittstelle des Anwendungsbausteins an die bereitstellende Schnittstelle als Parameter übermittelt werden. Die Art der als Parameter bereitzustellenden Daten wird durch die Angabe vn Objekttypen beschrieben. Möglicherweise sind aber für bestimmte Services auch keine Parameter erfrderlich. E.C.B-3.9 Interebenenbeziehung hat als Ergebnis zu Objekttyp Bei der Ausführung eines Services durch das bereitstellende Anwendungssystem kann ein Ergebnis berechnet werden. Die Art der als Ergebnis zurückübermittelten Daten wird durch die Angabe vn Objekttypen beschrieben. Wenn als Ergebnis keine Daten zurückübermittelt werden, die für das Mdellierungsziel erscheinen, z. B. weil lediglich eine Bestätigung des Empfangs der Parameter bzw. des Aufrufs des Services zurückübermittelt werden, kann auf die Mdellierung des Ergebnisses verzichtet werden. E.C.B-3.10 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Welcher Anwendungsbaustein stellt anderen Anwendungsbausteinen die Funktinalität zur Verfügung, die zur Erledigung einer bestimmten Aufgabe erfrderlich ist? Welcher Service wird vn Anwendungsbausteinen redundant bereitgestellt? Welche Anwendungsbausteine stellen Services bereit, die alle auch durch (mehrere) andere Anwendungsbausteine erledigt werden können? Verweis auf Text E.B.D-1, E.C.B-10 E.B.D-1, E.C.B-10 E.C.B-10 E.C.B-3.11 Mdellierungshinweise Durch die Mdellierung vn Services und ihren Beziehungen zu Objekttypen und Aufgaben kann dargestellt werden, auf welche Weise ein Anwendungsbaustein für andere Anwendungsbausteine nützlich ist. 60

63 E.C.B Servicerientierte Kmmunikatin: 3LGM²-S E.C.B-4 Serviceklasse E.C.B-4.1 Beschreibung des Knzepts Eine Serviceklasse fasst Services, die vm Mdellierer als gleichartig angesehen werden, zusammen. Serviceklassen können z. B. sein: HL7-Empfangsservice, Services für die Patientendatenverwaltung, Services für die Verwaltung der Patientenakte, Druckservices etc. Serviceklassen werden in den graphischen Darstellungen nicht als eigene Objekte dargestellt. E.C.B-4.2 Beziehung enthält zu Service Jeder Serviceklasse können beliebig viele Services zugerdnet werden. E.C.B-4.3 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Welche Anwendungsbausteine stellen Services einer bestimmten Serviceklasse bereit? Verweis auf Text E.C.B-10 E.C.B-5 Bereitstellende Schnittstelle E.C.B-5.1 Beschreibung des Knzepts Über eine bereitstellende Schnittstelle stellt ein Anwendungsbaustein Services für andere Anwendungsbausteine zur Verfügung. E.C.B-5.2 Beziehung kann bereitstellen zu Service Die bereitstellende Schnittstelle stellt genau die hier angegebenen Services zur Verfügung. E.C.B-5.3 Beziehung zu Kmmunikatinsverbindung Wenn die vn der bereitstellenden Schnittstelle zur Verfügung gestellten Services tatsächlich vn einer aufrufenden Schnittstelle genutzt werden, dann wird zwischen beiden Schnittstellen eine Kmmunikatinsverbindung mdelliert. E.C.B-6 Aufrufende Schnittstelle E.C.B-6.1 Beschreibung des Knzepts Über eine aufrufende Schnittstelle kann ein Anwendungsbaustein Services anderer Anwendungsbausteine nutzen. E.C.B-6.2 Beziehung kann aufrufen zu Service Die aufrufende Schnittstelle kann genau die hier angegebenen Services aufrufen, damit der Anwendungsbaustein sie nutzen kann. E.C.B-6.3 Beziehung zu Kmmunikatinsverbindung Wenn vn der aufrufenden Schnittstelle aufrufbare Services tatsächlich bei einer bestimmten bereitgestellten Schnittstelle aufgerufen werden, dann wird zwischen beiden Schnittstellen eine Kmmunikatinsverbindung mdelliert. E.C.B-7 Kmmunikatinsverbindung E.C.B-7.1 Beschreibung des Knzepts Dieses Knzept ist in Abschnitt E.B.D-3 bereits detailliert beschrieben. Für die Erweiterung 3LGM²-S sind jedch flgende Ergänzungen erfrderlich: 61

64 E.C.B Servicerientierte Kmmunikatin: 3LGM²-S Eine Kmmunikatinsverbindung zwischen einer aufrufenden und einer bereitstellenden Schnittstelle beschreibt, dass die aufrufende Schnittstelle tatsächlich bestimmte Services der bereitstellenden Schnittstelle aufruft. Gehen vn einer aufrufenden Schnittstelle mehrere Kmmunikatinsverbindungen zu bereitstellenden Schnittstellen aus, die jeweils dieselben Services nutzen, werden diese Kmmunikatinsverbindungen als Alternativen angesehen. Dies bedeutet, dass der aufrufende Anwendungsbaustein zur Laufzeit entscheidet, bei welchem bereitstellenden Anwendungsbaustein er den Service tatsächlich aufruft. E.C.B-7.2 Attribut ausführungsabhängig Über das Attribut ausführungsabhängig (ja/nein) kann mdelliert werden, b der den Service aufrufende Anwendungsbaustein mit seiner weiteren Datenverarbeitung erst frtfahren kann, wenn das Ergebnis der Serviceausführung durch den bereitstellenden Anwendungsbaustein zurückübermittelt wurde. Dies wäre z. B. bei synchrn abgewickelten Datenbankabfragen der Fall. Bei asynchrnem Nachrichtenversand wird dagegen in der Regel nicht vn einer Ausführungsabhängigkeit auszugehen sein. Eine Ausführungsabhängigkeit kann auch dann mdelliert werden, wenn ein Anwendungsbaustein AB die Erledigung einer Aufgabe A durch einen Nutzer unterstützt (vgl. E.B.B-2.4 und E.B.D-1.6), aber über eine entsprechende Kmmunikatinsverbindung einen Service D aufruft, der die dafür erfrderliche Funktinalität bereitstellt (vgl. E.C.B- 3.3). Genau dann wenn AB die Erledigung der Aufgabe A durch einen Nutzer nur dann unterstützen kann, wenn der Service D nach dem Aufruf erflgreich ausgeführt wurde, ist ausführungsabhängig mit ja zu mdellieren. Alternative Kmmunikatinsverbindungen (vgl. E.C.B-7.1) müssen alle als ausführungsabhängig bzw. alle als nicht ausführungsabhängig mdelliert sein. E.C.B-7.3 Beziehung realisiert Aufruf vn zu Service Die an der Kmmunikatinsverbindung beteiligte aufrufende Schnittstelle ruft tatsächlich genau die hier angegebenen Services auf. E.C.B-7.4 Mdellierungshinweise E.C.B-8 Für die Bewertung der Ausführungsabhängigkeit (siehe E.C.B-7.1) gibt es keine bjektiven Kriterien. Vielmehr bliegt es dem Mdellierer, eine Einschätzung vrzunehmen. Dabei ist zu berücksichtigen, dass der 3LGM²-Baukasten Analysen bereitstellt, mit denen auf der Basis dieser Angaben ermittelt wird, welche Anwendungsbausteine in hhem Maße vneinander abhängig sind. Die Mdellierung ist als klar an den Auswertungszielen auszurichten. Kmmunikatinsschnittstelle Dieses Knzept ist in Abschnitt E.B.D-3 bereits detailliert beschrieben. Für die Erweiterung 3LGM²-S sind jedch flgende Ergänzungen erfrderlich: Ein Anwendungsbaustein besitzt Kmmunikatinsschnittstellen, um mit anderen Anwendungsbausteinen kmmunizieren zu können. Eine aufrufende Schnittstelle eines Anwendungssystems kann Services eines anderen Anwendungssystems aufrufen, das diese Services über eine bereitstellende Schnittstelle bereitstellen kann. Wenn vn einer aufrufenden Schnittstelle tatsächlich Services einer bereitstellenden Schnittstelle aufgerufen werden, dann werden diese Kmmunikatinsschnittstellen durch eine Kmmunikatinsverbindung verbunden, die vn der bereitstellenden zu der aufrufenden Schnittstelle weist (vgl.e.c.b-7). Eine Kmmunikatinsschnittstelle kann nur aufrufende der bereitstellende Schnittstelle sein. Alle Kmmunikatinsschnittstellen eines Anwendungsbausteins gelten implizit als s untereinander verbunden, dass jede aufrufende Schnittstelle des Anwendungsbausteins auf alle Parameter aller bereitstellenden Schnittstellen des Anwendungsbausteins zugreifen kann. E.C.B-9 Aufgabe Dieses Knzept ist in Abschnitt E.B.B-2 bereits detailliert beschrieben. Für die Erweiterung 3LGM²-S sind jedch flgende Ergänzungen erfrderlich: 62

65 E.C.B Servicerientierte Kmmunikatin: 3LGM²-S E.C.B-9.1 Interebenenbeziehung kann aufrufen zu Service Im Unterschied zur Beziehung zur Klasse Nutzung (vgl. E.B.B-2.4) wird durch die Beziehung einer Aufgabe zu einem Service ausgedrückt, dass der Service interessierten Anwendungsbausteinen eine Funktinalität anbietet, die es den Anwendungsbausteinen ermöglicht, menschliche Nutzer bei der Erledigung der Aufgabe zu unterstützen. D. h. der Service kann nicht unmittelbar die Erledigung der Aufgabe unterstützen, sndern muss zu diesem Zweck vn einem Anwendungssystem genutzt werden. E.C.B-9.2 Beziehungen zu Nutzung Siehe E.B.B-2.4 (Anwendungsbaustein). E.C.B-9.3 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Verweis auf Text Welche Anwendungsbausteine sind erfrderlich, um menschliche Nutzer bei der Erledigung einer bestimmten Aufgabe zu unterstützen? Zur Erledigung welcher Aufgaben werden besnders viele verschiedene Services genutzt? E.C.B-9.4 Mdellierungshinweise Wenn für einen Anwendungsbaustein durch die Mdellierung einer Beziehung zu Nutzung beschrieben ist, dass er in einer bestimmten Organisatinseinheit eine bestimmte Aufgabe unterstützt, dann muss sichergestellt sein, dass er entweder die erfrderliche Funktinalität selbst implementiert (vgl. E.C.B-3.3) der aber über eine aufrufende Schnittstelle und entsprechende Kmmunikatinsverbindung mit einem anderen Anwendungsbaustein verbunden ist, der ihm einen Service bereitstellt, welcher die erfrderliche Funktinalität bietet (vgl. E.C.B-9.1). Die explizite Mdellierung vn Kmmunikatinsverbindungen zwischen Kmmunikatinsschnittstellen desselben Anwendungsbausteins ist nicht vrgesehen (siehe E.B.D-3). E.C.B-10 Anwendungsbaustein Dieses Knzept ist in Abschnitt E.B.D-1 bereits detailliert beschrieben. Für die Erweiterung 3LGM²-S sind jedch flgende Ergänzungen erfrderlich: E.C.B-10.1 Beziehung vermittelt zu Kmmunikatinsverbindung In Architekturen, die sich z. B. an CORBA der DCOM rientieren, sind Anwendungsbausteine vrgesehen, die zur Laufzeit einem Anwendungsbaustein AB, der einen bestimmten Service D aufrufen möchte, auf Anfrage einen Anwendungsbaustein AB benennen, der zu diesem Zeitpunkt dazu in der Lage ist, den Service D bereitzustellen und auszuführen (vgl. [16], S. 106 ff.). Durch die Beziehung vermittelt wird ausgedrückt, dass ein Anwendungsbaustein VB in diesem Sinne die entsprechende Kmmunikatinsverbindung vermittelt. Ein slcher Anwendungsbaustein wird auch als Vermittlungsbaustein bezeichnet. Es ist nicht vrgesehen explizit zu mdellieren, dass zu diesem Zweck die Anwendungsbausteine AB und AB bestimmte Vermittlungsservices des Vermittlungsbausteins VB aufrufen (vgl. [16], S. 106 ff) der dass der Vermittlungsbaustein VB slche Vermittlungsservices bereitstellt; vielmehr wird implizit davn ausgegangen, dass VB slche Vermittlungsservices bereitstellt und dass swhl AB und AB diese Services in Anspruch nehmen. Zur Darstellung siehe Abbildung

66 E.C.B Servicerientierte Kmmunikatin: 3LGM²-S Abbildung 17: Darstellung eines Vermittlungsbausteins E.C.B-10.2 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Verweis auf Text Auf welche anderen Anwendungsbausteine ist ein Anwendungsbaustein angewiesen, damit er wie angegeben menschliche Nutzer bei der Erledigung bestimmter Aufgaben unterstützen kann? E.C.B-10.3 Mdellierungshinweise Siehe E.C.B-9.3. E.C.B-11 Objekttyp Dieses Knzept ist in Abschnitt E.B.B-1 bereits detailliert beschrieben. Für die Erweiterung 3LGM²-S sind jedch flgende Ergänzungen erfrderlich: E.C.B-11.1 Interebenenbeziehung hat als Parameter zu Service Wenn ein Objekttyp Parameter eines Services ist, bedeutet das, dass der Service Daten über Objekte der Objektklasse erwartet, auf die der Objekttyp verweist. Nur dann, wenn diese Daten bereitgestellt werden, kann der Service ausgeführt werden. E.C.B-11.2 Interebenenbeziehung hat als Ergebnis zu Service Wenn ein Objekttyp Ergebnis eines Services ist, bedeutet das, dass der Service Daten über Objekte der Objektklasse erzeugt, auf die der Objekttyp verweist. Diese Daten werden bereitgestellt, sbald der Service ausgeführt wurde. E.C.B-11.3 Fragen des Infrmatinsmanagements und Unterstützung durch das 3LGM² Fragen des Infrmatinsmanagements Verweis auf Text Welche Anwendungsbausteine sind auf Daten über diesen Objekttyp angewiesen? Vn welchen Anwendungssystemen werden Daten über diesen Objekttyp erzeugt? E.C.B-11.4 Mdellierungshinweise Siehe Abschnitt E.B.B-1.8. E.C.B-12 Knvertierung vn Mdellen zwischen 3LGM²-B und 3LGM²-S E.C.B-12.1 Knvertierung vn 3LGM²-B nach 3LGM²-S Die Knvertierung ist verlustls, benötigt aber ein Eingreifen des Mdellierers. 64

67 E.C.B Servicerientierte Kmmunikatin: 3LGM²-S Wenn eine Kmmunikatinsschnittstelle swhl Sende- als auch Empfangsschnittstelle ist, muss sie in zwei getrennte Schnittstellen aufgespalten werden (vgl. E.C.B-7.4). Eine Sendeschnittstelle, die bestimmte Objekttypen senden kann, wird wie flgt knvertiert: aus der Sendeschnittstelle wird eine aufrufende Schnittstelle; für jeden Objekttyp werden n Services receive_<name des Objekttyps>_Nachrichtentyp_x (x=1 n, x ) eingerichtet, die die Objekttypen als Parameter erwarten. Es werden als entsprechend der Anzahl n der Kmmunikatinsverbindungen, über die der Objekttyp gesendet wird, Dummy-Nachrichtentypen zu jedem Objekttyp erzeugt. Es wird empfhlen, dass der Mdellierer den Nachrichtentypen nachträglich aussagekräftigere Namen gibt bzw. manuell gleiche Nachrichtentypen vereinigt. Die Services werden autmatisch der aufrufenden Schnittstelle zugerdnet; Serviceklassen können nicht autmatisch erzeugt werden, sndern müssen manuell mdelliert werden. Eine Empfangsschnittstelle, die bestimmte Nachrichtentypen empfangen kann, wird wie flgt knvertiert: aus der Sendeschnittstelle wird eine bereitstellende Schnittstelle; für jeden Nachrichtentyp (der beim Erzeugen der Sendeschnittstellen autmatisch generiert wurde) wird ein Service receive_<name des Objekttyps>_Nachrichtentyp_x eingerichtet, der die Objekttypen als Parameter erwartet, zu denen der Nachrichtentyp in Beziehung steht. Diese Services werden der bereitstellenden Schnittstelle zugerdnet; Serviceklassen können nicht autmatisch erzeugt werden, sndern müssen manuell mdelliert werden. Eine Kmmunikatinsverbindung, die bestimmte Objekttypen versendet, wird wie flgt knvertiert: die neue Kmmunikatinsverbindung verbindet die aufrufende Schnittstelle und bereitstellende Schnittstelle, deren vrausgehende Sende- und Empfangsschnittstelle zuvr bereits durch die Kmmunikatinsverbindung verbunden waren; die neue Kmmunikatinsverbindung wird zu all den Services in Beziehung gesetzt, die zu den Nachrichtentypen passen, die über die Kmmunikatinsverbindung gesendet werden. Der Benutzer wird aufgefrdert, die unmittelbaren Beziehungen vn Aufgabe zu Service (siehe E.C.B-3.3) und Anwendungsbaustein (siehe E.C.B-10.1) vn Hand nachzumdellieren. Die entsprechenden Infrmatinen können nicht aus dem alten Mdell entnmmen werden. E.C.B-12.2 Knvertierung vn 3LGM²-S nach 3LGM²-B Die Knvertierung ist nicht verlustls, benötigt aber kein Eingreifen des Mdellierers. Eine aufrufende Schnittstelle, die bestimmte Services aufrufen kann, wird wie flgt knvertiert: eine aufrufende Schnittstelle wird in zwei Schnittstellen aufgeteilt: eine Empfangsschnittstelle e1 und eine Sendeschnittstelle s1. der Objekttyp 1, den der aufgerufene Service als Parameter hat, wird der Sendeschnittstelle s1 zugerdnet. der Objekttyp 2, den der aufgerufene Service als Ergebnis hat, wird der Empfangsschnittstelle e1 zugerdnet. Eine bereitstellende Schnittstelle, die bestimmte Services bereitstellt, wird wie flgt knvertiert: eine bereitstellende Schnittstelle wird in 2 Schnittstellen aufgeteilt: eine Empfangsschnittstelle e2 und eine Sendeschnittstelle s2. der Objekttyp 2, den der bereitgestellte Service als Ergebnis hat, wird der Sendeschnittstelle s2 zugerdnet. der Objekttyp 1, den der bereitgestellte Service als Parameter hat, wird der Empfangsschnittstelle e2 zugerdnet. Eine Kmmunikatinsverbindung, die den Aufruf vn Services realisiert, wird wie flgt knvertiert: 65

68 E.C.B Servicerientierte Kmmunikatin: 3LGM²-S Es wird eine Kmmunikatinsverbindung vn s1 nach e2 angelegt, dieser wird der Objekttyp 1 zugerdnet. Es wird eine Kmmunikatinsverbindung vn s2 nach e1 angelegt, dieser wird der Objekttyp 2 zugerdnet. Der Service und übergerdnete Serviceklassen werden gelöscht. E.C.B-13 Knvertierung vn Mdellen zwischen 3LGM²-M und 3LGM²-S Der 3LGM²-Baukasten unterstützt die Knvertierung vn Mdellen zwischen 3LGM²-M und 3LGM²-S. E.C.B-13.1 Knvertierung vn 3LGM²-M nach 3LGM²-S Die Knvertierung ist verlustls, benötigt aber ein Eingreifen des Mdellierers. Wenn eine Kmmunikatinsschnittstelle swhl Sende- als auch Empfangsschnittstelle ist, muss sie in zwei getrennte Schnittstellen aufgespalten werden (vgl.e.c.b-7.4). Eine Sendeschnittstelle, die bestimmte Nachrichtentypen versenden kann, wird wie flgt knvertiert: aus der Sendeschnittstelle wird eine aufrufende Schnittstelle; für jeden Nachrichtentyp wird ein Service receive_<name des Nachrichtentyps> eingerichtet, der die Objekttypen als Parameter erwartet, zu denen der Nachrichtentyp in Beziehung steht. Diese Services werden der aufrufenden Schnittstelle zugerdnet. für jeden Kmmunikatinsstandard, zu dem die Nachrichtentypen in Beziehung stehen, wird eine Serviceklasse <Name des Kmmunikatinsstandards>_receive eingerichtet, der der jeweils entsprechende zuvr definierte Service zugerdnet wird. Eine Empfangsschnittstelle, die bestimmte Nachrichtentypen empfangen kann, wird wie flgt knvertiert: aus der Sendeschnittstelle wird eine bereitstellende Schnittstelle; für jeden Nachrichtentyp wird ein Service receive_<name des Nachrichtentyps> eingerichtet, der die Objekttypen als Parameter erwartet, zu denen der Nachrichtentyp in Beziehung steht. Diese Services werden der bereitstellenden Schnittstelle zugerdnet. für jeden Kmmunikatinsstandard, zu dem die Nachrichtentypen in Beziehung stehen, wird eine Serviceklasse <Name des Kmmunikatinsstandards>_receive eingerichtet, der der jeweils entsprechende zuvr definierte Service zugerdnet wird. Eine Kmmunikatinsverbindung, die bestimmte Nachrichtentypen versendet, wird wie flgt knvertiert: Die neue Kmmunikatinsverbindung verbindet die aufrufende Schnittstelle und bereitstellende Schnittstelle, deren vrausgehende Sende- und Empfangsschnittstelle zuvr bereits durch die Kmmunikatinsverbindung verbunden waren. Die neue Kmmunikatinsverbindung wird zu all den Services in Beziehung gesetzt, die zuvr aus Nachrichtentypen abgeleitet wurden und zu den Nachrichtentypen passen, die über die Kmmunikatinsverbindung gesendet werden. Der Benutzer wird aufgefrdert, die unmittelbaren Beziehungen vn Aufgabe zu Service (siehe E.C.B-3.3) und Anwendungsbaustein (siehe E.C.B-10.1) vn Hand nachzumdellieren. Die entsprechenden Infrmatinen können nicht aus dem alten Mdell entnmmen werden. E.C.B-13.2 Knvertierung vn 3LGM²-S nach 3LGM²-M Die Knvertierung ist nicht verlustls, benötigt aber auch kein Eingreifen des Mdellierers. Eine aufrufende Schnittstelle, die bestimmte Services aufrufen kann, wird wie flgt knvertiert: eine aufrufende Schnittstelle wird in zwei Schnittstellen aufgeteilt: eine Empfangsschnittstelle e1 und eine Sendeschnittstelle s1. für den Objekttyp 1, den der aufgerufene Service als Parameter hat, wird ein Nachrichtentyp 1_Nachrichtentyp_x (x=1 n, x ) angelegt, dieser wird der Sendeschnittstelle s1 zugerdnet. 66

69 E.C.B Servicerientierte Kmmunikatin: 3LGM²-S Die Serviceklasse, die dem aufgerufenen Service zugerdnet ist, wird in einen Kmmunikatinsstandard umgewandelt und der generierte Nachrichtentyp wird diesem zugerdnet. für den Objekttyp 2, den der aufgerufene Service als Ergebnis hat, wird ein Nachrichtentyp 2_Nachrichtentyp_x (x=1 n, x ) angelegt, dieser wird der Empfangsschnittstelle e1 zugerdnet. Die Serviceklasse, die dem aufgerufenen Service zugerdnet ist, wird dem generierten Nachrichtentyp als Kmmunikatinsstandard zugerdnet. Eine bereitstellende Schnittstelle, die bestimmte Services bereitstellt, wird wie flgt knvertiert: eine bereitstellende Schnittstelle wird in zwei Schnittstellen aufgeteilt: eine Empfangsschnittstelle e2 und eine Sendeschnittstelle s2. Der Nachrichtentyp 2_Nachrichtentyp_x wird der Sendeschnittstelle s2 zugerdnet. Der Nachrichtentyp 1_Nachrichtentyp_x wird der Empfangsschnittstelle e2 zugerdnet. Werden die Objekttypen 1 und 2 auch an anderer Stelle zwischen Anwendungsbausteinen kmmuniziert, s werden neue zugehörige Nachrichtentypen angelegt, der Zähler x im Namen des Nachrichtentypen wird dabei inkrementiert. Eine nachträgliche Umbenennung der autmatisch generierten Nachrichtentypen der die Vereinigung vn Nachrichtentypen seitens des Mdellierers wird empfhlen. Eine Kmmunikatinsverbindung, die den Aufruf vn Services realisiert, wird wie flgt knvertiert: Es wird eine Kmmunikatinsverbindung vn s1 nach e2 angelegt, dieser wird der Nachrichtentyp 1_Nachrichtentyp_x zugerdnet. Es wird eine Kmmunikatinsverbindung vn s2 nach e1 angelegt, dieser wird der Nachrichtentyp 2_Nachrichtentyp_x zugerdnet. Der Service wird gelöscht. 67

70 F Anfrderungen an den 3LGM²-Baukasten F Anfrderungen an den 3LGM²-Baukasten F.A Darstellung vn 3LGM²-Mdellen im 3LGM²-Baukasten Ein Mdell besteht im 3LGM²-Baukasten aus einem sgenannten Gesamtmdell und beliebig vielen Teilmdellen. Das Gesamtmdell enthält jeweils alle Elemente eines knkreten Mdells mit all ihren Eigenschaften, die durch das Metamdell definiert sind. Teilmdelle sind eine eingeschränkt beliebige Auswahl aus den Elementen des Gesamtmdells. Eingeschränkt beliebig bedeutet, dass es Elementarten gibt, vn denen sämtliche Instanzen autmatisch in jedem Teilmdell vrhanden sind, und Elemente, bei denen explizit durch einen Mdellierer festgelegt werden muss, b sie in dem jeweiligen Teilmdell enthalten sind der nicht. Zur Visualisierung des Gesamtmdells swie der Teilmdelle stehen flgende Sichten zur Verfügung: F.A.A Baumansicht Abbildung 18: Beispiel einer Baumansicht eines Teilmdells Die Baumansicht eines Gesamtmdells der Teilmdells stellt in der bersten Hierarchiestufe die drei Gegenstandsebenen dar und darunter jeweils alle 3LGM²-Knzepte, die der jeweiligen Gegenstandsebene zugerdnet sind. Unterhalb der Knten, die die 3LGM²-Elementklassen repräsentieren, werden evtl. hierarchisch gegliedert über Ist-Teil-Vn-Beziehungen alle knkreten Elemente des Teil- bzw. Gesamtmdells angezeigt. Das Beispiel in Abbildung 18 stellt eine slche Baumansicht für ein Teilmdell mit dem Namen KMDS-RIS-PACS dar. Der fachlichen Gegenstandsebene sind die 3LGM²-Knzepte Aufgabe, Objekttyp, Organisatinseinheit, Przess 68

71 F Anfrderungen an den 3LGM²-Baukasten und Rlle des vrhergehenden Metamdells zugerdnet. Unterhalb des Kntens Aufgabe kann man die in diesem Teilmdell enthaltenen knkreten Aufgaben erkennen. Die Aufgabe Radilgische Diagnstik besitzt in diesem Beispiel drei Teilaufgaben, die ihr untergerdnet sind. F.A.B Grafische Einzelebenenansicht Zu jedem Teilmdell (aber nicht zum Gesamtmdell) gibt es jeweils drei sgenannte Einzelebenenansichten. Jede dieser Einzelebenenansichten stellt ausschließlich eine Auswahl der Knzepte jeweils einer der drei Gegenstandsebenen dar. Sie werden smit als grafische Sicht der Fachlichen Ebene, der Lgischen Werkzeugebene und der Physischen Werkzeugebene bezeichnet. Die Sichten selbst sind zweidimensinale Graphen auf einer in ihren Ausmaßen beschränkten Zeichenebene. Aufgrund dieser Eigenschaften werden die Begriffe Fachliche Ebene, Lgische Werkzeugebene und Physische Werkzeugebene ft synnym für die jeweilige Gegenstandsebene des Metamdells der ganz speziell für die grafische Darstellung eines Teilmdells in der jeweiligen Einzelebenenansicht verwendet. In Abbildung 6 ist ein Beispiel für die grafische Sicht einer Fachlichen Ebene zu sehen und in Abbildung 14 ist die grafische Repräsentatin der Physischen Werkzeugebene eines Teilmdells dargestellt. Abbildung 6 zeigt eine Fachliche Ebene, wie sie swhl im bestehenden 3LGM²-Baukasten, als auch in Zukunft mit den in diesem Dkument definierten Knzepten aussieht bzw. aussehen wird. Keine der drei grafischen Einzelebenenansichten stellt alle Knzepte der zugehörigen Gegenstandsebene dar, sndern sie beschränken sich aus Gründen der Übersichtlichkeit auf die in den meisten Anwendungsfällen wichtigsten Knzepte und deren Zusammenhänge der jeweiligen Gegenstandsebene. S besitzen z. B. Elemente der Klasse Organisatinseinheit in der grafischen Ansicht der Fachlichen Ebene anders als in der Baumansicht keine Repräsentatin. Alle diese Einzelsichten beschreiben Infrmatinssysteme vrwiegend statisch in ihrer Struktur. Zusätzlich dazu kann man in der grafischen Sicht der Fachlichen Ebene und der Lgischen Werkzeugebene nch eine dynamische Perspektive einblenden, die die Abläufe auf den Strukturen verdeutlichen (vgl. berer Teil vn Abbildung 8). F.A.C Grafische 3-Ebenen-Ansicht Diese Sicht stellt die drei grafischen Einzelsichten eines Teilmdells übereinander in der Reihenflge Fachliche Ebene, Lgische Werkzeugebene und Physische Werkzeugebene (vn ben nach unten) dar. Abbildung 19 zeigt die grafische 3- Ebenen-Ansicht eines Beispielteilmdells. Über diese Ansicht können auch die Beziehungen grafisch repräsentierter Elemente der direkt übereinander liegenden Einzelebenen visualisiert werden. Diese Beziehungen verbinden im Metamdell die einzelnen Gegenstandsebenen und finden in der grafischen 3-Ebenen-Ansicht ihre Entsprechung als Linien zwischen den grafischen Einzelebenenansichten. Sie werden swhl im Metamdell als auch in der grafischen Darstellung eines knkreten Mdells als Inter-Ebenen-Beziehungen bezeichnet. 69

72 F Anfrderungen an den 3LGM²-Baukasten Abbildung 19: Beispiel einer grafischen 3-Ebenen-Ansicht F.A.D Matrixsicht Über eine Matrixsicht lässt sich jeweils für eine Kmbinatin aus zwei Elementklassen des Metamdells anzeigen, b die knkreten Elemente eines Mdells über Assziatinen miteinander verbunden sind. 70

73 F Anfrderungen an den 3LGM²-Baukasten F.A.E Eigenschaftsdialge Für jedes Mdellelement existiert ein Eigenschaftsdialg, in dem u.a. der Name und die Beschreibung des Elements editiert werden können, Verbindungen zu anderen Elementen hergestellt werden können, benutzerdefinierte Eigenschaften in Frm vn Text, Auswahllisten, Radibuttns, Hyperlinks, Checkbxes und Kennzahlen bzw. Kennzahlfrmeln angegeben werden können. Der 3LGM²-Baukasten verfügt ab der Versin 3.2 über kmplexe Funktinen zur Kennzahlverrechnung 6 gemäß [33]. Siehe als Beispiel Abbildung 9. F.B Aktuelle Versin des 3LGM²-Baukastens April 2010: Der 3LGM²-Baukasten ist in der Versin verfügbar 7. F.C Anfrderungen an den 3LGM²-Baukasten aus dem Metamdell F.C.A Anfrderungen seitens der Elementklassen F.C.A-1.1 Aufgabe Siehe E.B.B