Diplomarbeit

Design einer Datenbank

für

kontextspezifische Daten, Pläne und deren zeitlichen Verlauf

(Asgaard – Datenbanklayer "Skid")

 Kurzfassung

Inhalt

 

ausgeführt am

Institut für Softwaretechnik

der Technischen Universität Wien

(o. Univ.-Prof Dr. A Min Tjoa)

 

unter der Anleitung von

o. Univ.-Prof Dr. A Min Tjoa

Univ.-Ass. Dr. Silvia Miksch

 

durch

Klaus Hammermüller

Meytensg. 35

1130 Wien

 

Wien, im April 1998

 

meinen Eltern gewidmet

 


Um die Lesbarkeit und die Verständlichkeit der Diplomarbeit nicht zu erschweren, wird durchgehend die männliche Form für beide Geschlechter verwendet.

 

Kurzfassung

 

Diese Arbeit ist Teil des "Asgaard" Projekts, das Planungsprozesse mit geeigneten Softwarewerkzeugen unterstützt. Aufgrund der Erfahrungen des VIE-VENT Projekts entstand innerhalb des "Asgaard" Projekts die zeit- und intentionsbasierten Sprache "Asbru" mit der Planungsprobleme geeignet repräsentiert werden können.

 

Ziel dieser Arbeit ist es die anfallenden Daten und Pläne wiederverwertbar zu machen. Dazu wird zuerst eine Prozeßmodellierung des "Asgaard" Projekts vorgenommen und daraus ein geeignetes Datenmodell entwickelt. In dem Vorprojekt "CTS" wurde dies mit einem relationalen Datenbankmodell versucht. Die resultierende Fülle an Relationen und die dadurch verursachte schlechte Wiederverwendbarkeit der erfaßten Informationen zeigten die Grenzen dieses Modells auf. Deshalb sollen "Informationseinheiten" gefunden werden, die auf einfache Weise miteinander "verbunden" werden können. In Konsequenz sollen Pläne von den Rohdaten getrennt werden, um eine bessere Vernetzung zu erreichen.

 

Ziel dieser Aufgabe ist die Erstellung eines Datenbankprototypen "Skid", der

 

Die entstehenden Datenstrukturen sollen a priori unabhängig von der gewählten Problemdomäne sein. Im Fall des CTS-Projekts war dies Trainingsplanung und -durchführung im Leistungssport und ist sehr umfassend in der Praxis getestet worden. Das Asgaard-Projekt behandelt medizinische Therapieplanung. Der medizinische und der sportliche Kontext ähneln einander, da mit einfachen Maßnahmen im komplexen biologischen System des menschlichen Körpers gezielt Reaktionen erreicht werden sollen. Die wechselseitigen Synergien werden in dieser Arbeit wiederholt angesprochen. 


Inhalt

1. Einführung

1.1. Die Idee

1.1.1. Asgaard

1.1.2. Computerunterstütztes Trainingssystem (CTS)

1.1.3. Gemeinsamkeiten und Unterschiede von Asgaard und CTS

1.2. Lehren aus dem CTS-Projekt

1.2.1. Projektebenen

1.2.2. Rollenverteilung

1.2.3. Zielgruppen

1.3. Aufgetretene Probleme und Lösungsansätze

1.3.1. Soziologische Ebene

1.3.2. Kontextuelle Ebene

1.3.3. Konzeptebene

1.3.4. Methodische Ebene

1.3.5. Grenzen

2. Verwendetes Paradigma

2.1. Planrepräsentation mit Asbru

2.1.1. Die Idee

2.1.2. Planhierarchie

2.2. Java & JDBC

2.2.1. Systemkomponenten

2.2.2. Systemarchitektur

2.2.3. Datenbank-Treiber

2.3. Alternativen

2.3.1. Adaptive Algorithmen

2.3.2. Gewählte Sprache

2.3.3. Gewählte Datenbank

3. Anforderungen

3.1. Zieldefinition

3.1.1. Thema

3.1.2. Erfolg

3.1.3. "Unique Selling Point"

3.1.4. Zielsetzung

3.2. Arbeitsablauf

3.3. Taskstruktur von Asgaard

4. Design

4.1. Systemmodell

4.1.1. Funktionale Gruppierung

4.1.2. Datenbank - Metamodell

4.1.3. UI-Komponenten

4.2. Datenmodell

4.2.1. Datenfluß

4.2.2. Datenoperationen

4.2.3. Datentypen

4.2.4. Datenklassen

4.2.5. EER – ein Lösungsansatz

4.3. Implementation

4.3.1. EER - Implementiertes Modell

4.3.2. OOD-Datenobjekte

5. Conclusio

5.1. Reuse & Knowledge Discovering Databases

5.2. Auswahl und Klassifikation

5.3. Verteilte Komponenten

6. Anhänge

6.1. Hierarchiediagramm

6.1.1. Hierarchien (Arbeitsvorgänge)

6.1.2. Trigger (Auslöser)

6.1.3. Ressourcen (Betriebsmittel)

6.1.4. Beziehungen

6.2. Datenbank API "Skid"

6.3. Instalation

6.3.1. Bestandteile

6.3.2. Installation

Danksagung

Literatur

Bildnachweis

Lebenslauf


 

1 Einführung

In vielen Bereichen des Lebens stehen für Analysen keine umfassenden mathematischen Modelle zur Verfügung. Zumeist deshalb, weil die Zusammenhänge unklar sind, zu viele Einflußfaktoren existieren oder diese nicht präzise genug dargestellt werden können.

 

Es gibt vielfältige Lösungsansätze, zumeist wird dabei die Komplexität der Problemstellung aber ignoriert (Abbildung 1). In meiner Diplomarbeit ist mir wichtig, den Bezug wissenschaftlicher Modelle mit der Realität herzustellen, um diese in der Praxis nutzen zu können. Es soll möglich sein, komplexe Problemstrukturen mit einer zeitorientierten Sprache abzubilden und die Vielfalt an Information derart zu organisieren, daß empirische Problemlösungsprozesse durch unterschiedliche Analysemethoden unterstützt werden. Ich glaube auch, daß in unterschiedlichen Fragestellungen oder in verschiedenen Bearbeitungsstufen von Information verschiedene Ansätze notwendig sind, um in einem Problemlösungsprozeß ergänzende Standpunkte zu ermöglichen.

 

Dabei ist mir wichtig, dies in der "Wirklichkeit" zu tun. In einem Vorprojekt ("CTS") haben wir versucht den Trainingsprozeß im Leistungssport zu unterstützen. Als ehemaliger aktiver Ruderer und "aktiver" Trainer ist die Motivation für meinen Weg offensichtlich. Diese Arbeit ist Teil des Projekts "Asgaard" das in der medizinischen Therapieplanung eingesetzt werden soll und für mich eine logische Weiterentwicklung.

Zurück zum Inhalt

 

1.1 Die Idee

Diese Arbeit basiert auf zwei Projekten, deren Gemeinsamkeit die bessere Verwertung von Wissen im Umgang mit komplexen biologischen Prozessen ist. Es geht um die Rationalisierung von Steuerungsmaßnahmen bzw. Eingriffen in solche Prozesse im medizinischen (Asgaard) bzw. sportlichen (CTS) Kontext. Dazu sollen unter anderem laufend gesetzte Qualitätskriterien überprüft werden, um die Erfolgswahrscheinlichkeit zu optimieren.

 

Zielsetzung

Zurück zum Inhalt

 

1.1.1 Asgaard

Das Asgaard-Projekt [Shahar98] wird von einer internationalen Projektgruppe [Asgaard] betrieben. Asgaard verfolgt einen Top-Down Ansatz mit dem versucht wird Theorie in der Praxis anzuwenden. [Shahar97]: Klinische Protokolle sollen Wissen über klinische Arbeitsabläufe wiederverwenden und dabei flexibel genug sein, um dieses Wissen umsetzen zu können. Protokolle können als generische skeletale Planschemata gesehen werden, die vom medizinisches Personal über signifikante Zeiträume umgesetzt und dabei in einer dynamischen Umgebung verfeinert werden. Im Asgaard-Projekt werden die für die Erstellung und Verwendung solcher Protokolle durch medizinisches Personal notwendigen Methoden zur Verfügung gestellt. Im Zentrum der Überlegungen steht die Umsetzung von Protokollen durch das medizinische Personal, dabei werden aufgrund der beabsichtigten Zielsetzung der gesetzten Aktionen die Umsetzung an einem Patienten anhand dessen medizinischen Daten überwacht. Dazu müssen Methoden entwickelt werden, die den Einsatz in unterschiedlichen medizinischen Problemdomänen aufgrund der klinischen Protokolle und der elektronischen Krankengeschichte ermöglichen.

Die Ziele, die dieses Projekt verfolgt sind:

 

Ein wichtiges Element zur Umsetzung dieses Zieles ist die Sprache Asbru, [Miksch97a]

Asbru unterstützt die Repräsentation von zeitbezogenen skeletalen Plänen und ermöglicht anhand verschiedener Wissenskomponenten ("knowledge roles") die Entwicklung von aufgabenorientierten Methoden ("task-specific problem solving methods") zu implementieren (siehe Kapitel 3.3 Seite *). Dabei wird modelliert, daß Zustandsänderung durch eine Aktion nicht abrupt, sondern auch kontinuierlich erfolgen können und danach bestimmbar sein soll, ob die zugrundeliegenden Absichten erreicht wurden oder nicht. Realisiert wird das mit einem hierarchischen Konzept an Plänen, die jeweils weitere verfeinerte Pläne oder konkrete Aktionen enthalten. Wissen kann in hohem Maße wiederverwendet werden, da die Verbindung der Patientendaten mit den skeletalen Plänen erst zur Laufzeit erfolgt. Die Begriffe "Plan" und "Protokoll" beziehen sich in Folge auf die gleichen Asbru-Strukturen, wobei "Plan" sich an der Zukunft und "Protokoll" an der Vergangenheit orientiert.

 

Asbru wurde in unterschiedlichen medizinischen Szenerien (z.B: Schwangerschaftsdiabetis [Miksch97a]) erprobt. Momentan wird im Asgaard-Projekt Software entwickelt, die einen eigenständigen Einsatz durch medizinisches Personal zuläßt, um ausreichend Wissen für die weitere Forschung sammeln zu können.

Zurück zum Inhalt 

 

1.1.2 Computerunterstütztes Trainingssystem (CTS)

Das CTS-Projekt [Hammer97a] verfolgt einen Bottom-Up Ansatz, um in der Praxis Daten für wissenschaftlich fundierte Analysen zu sammeln. "CTS" entstand in interdisziplinärer Zusammenarbeit der BAfL Wien (Bundesanstalt für Leibeserziehung), HSNS (Heeressport- und Nahkampfschule), dem IfS (Institut für Sportwissenschaften der UNI Wien), Sportlern und Trainern unterschiedlicher Verbände und Studenten der TU Wien. Es wurde sowohl in der Lehre (Trainerausbidung der BAfL Wien), als auch in der Praxis eingesetzt, unter anderen im Rudern, Schwimmen, Leichtathletik sowie in militärisch geförderten Sportarten auf Nationalkaderniveau und im Nachwuchsbereich.

 

Die Ziele, die in diesem Projekt erreicht wurden, sind:

 

Die größte Schwierigkeit lag darin, das Programm so zu gestalten, daß es in Bedienung und Arbeitsaufwand vom jeweiligen Sportler bzw. Trainer auch tatsächlich verwendet werden konnte. Die Lösung dieser Problematik hat auch in dieser Arbeit Relevanz, da ein Werkzeug für den Praxiseinsatz geschaffen werden soll.

 

Die wichtigste technische Eigenschaft ist, daß die Datenbankstruktur verteilt erweitert werden kann und die replizierten Daten trotzdem konsistent bleiben. Im Einsatz hatten wir dann eine Struktur zur Beschreibung sportlicher Leistung gefunden, die von den verwendeten Inhalten unabhängig ist und deshalb in verschiedenen Sportarten eingesetzt werden kann. Dabei wurde nicht generalisiert, sondern der Detaillierungsgrad der Dokumentation blieb weiterhin dem jeweiligen Benutzer überlassen.

 

Folgende Ziele konnten nicht erreicht werden, da eine geeignete Repräsentationsform von Wissen fehlte:

Zurück zum Inhalt 

 

1.1.3 Gemeinsamkeiten und Unterschiede von Asgaard und CTS

Beide Projekte haben das Bestreben mit einfachen Maßnahmen auf einen hochkomplexen Prozeß einzuwirken. Dabei werden künstlich Reize gesetzt (in Asgaard: Therapie, in CTS: Training) in der Hoffnung, daß sich der Körper in gewünschter Weise (Zielsetzung) anpaßt (Krankheitsverlauf vs. Leistungsentwicklung). Dazu benötigt man Wissen über das Wirken einzelner Einflußfaktoren (medizinisch, sportwissenschaftliches Wissen) im Kontext eines Individuums (Diagnose).

 

Die Idee diese beiden Projekte zusammenzuführen liegt einerseits in der Synergie der unterschiedlichen Arbeiten mit sich ergänzenden Erfahrungsfeldern und andererseits in der ähnlichen Thematik. Leider ist die Umsetzung nicht ganz so einfach, wie es auf den ersten Blick scheinen mag:

 

Die beiden Projekte unterscheidet, daß ein Arzt eher über Querschnittsdaten arbeitet, d.h. er kennt sehr viele ähnliche Fälle und behandelt, wenn ein Problem akut auftritt. Dabei ist er die agierende Person, der Patient bleibt oft (nicht immer) in einer passiven Rolle. Der Patient wird unter standardisierten Bedingungen (Krankenhaus) gehalten, bei denen Störgrößen nachvollziehbar sind, der behandelnde Arzt kann aber öfter wechseln.

Ein Trainer betreut meist wenige Sportler über sehr lange Zeiträume (Jahre) und arbeitet hauptsächlich mit Längsschnittdaten. Der eigentliche Akteur ist der Athlet und die gesetzten Maßnahmen müssen sehr fein dosiert werden. Training hat einen kontinuierlicheren Charakter als eine Krankheit (solange diese nicht chronisch ist) und ist den vollen Schwankungen eines "normalen" Lebens ausgesetzt.

 Zurück zum Inhalt

 

1.2 Lehren aus dem CTS-Projekt

Bei dem "CTS" Projekt stand der Einsatz in der Praxis im Vordergrund. Um ein Projekt erfolgreich bis zur tatsächlichen Benutzung zu bringen, darf es nicht nur auf ein Thema, z.B. ein sportwissenschaftliches Konzept fixiert werden. Es sind mehrere unterschiedliche Bereiche erfolgreich zu bearbeiten. Das Produkt muß in jedem die erforderlichen Kriterien erfüllen.

Zurück zum Inhalt

 

1.2.1 Projektebenen

Es geht darum ein Werkzeug zu schaffen, eine Idee zu entwickeln, wie dieses Werkzeug verwendet werden kann, die handwerklichen Fähigkeiten zu erarbeiten, dies in der Praxis auch erfolgreich anzuwenden und dafür zu sorgen, daß die Betroffenen es auch tun. Der Anforderungskatalog muß also mehrere Ebenen berücksichtigen, die unterschiedliche Ziele haben (Abbildung 2):

 

 Ebene

 Ziel


 Soziologie

Alle Maßnahmen, damit das System vom Benutzer tatsächlich eingesetzt wird. Orientierung am tatsächlichen Resultat.

 Kontext

Bezug der Aktivitäten zwischen Modell und Realität.

Konzept

Eine Modell, das helfen soll in der Realität gewünschte Effekte zu erzielen.

Methodik

Verwendete Werkzeuge.

Abbildung 2 Projektebenen

 

Soziologische Ebene

Zirka 30% des Aufwandes in diesem Projekt (Auswertung des Projekttagebuches [Hammer97b]) lief in die Bearbeitung dieser Ebene, mit starken Auswirkungen an das Design. So mußte z.B. das Userinterface überarbeitet werden, um den Fähigkeiten des typischen Benutzers entgegenzukommen.

 

Kontextuelle Ebene

Der entscheidende Bereich in diesem Projekt war zu zeigen, daß jeweils im speziellen Fall die Umsetzung des sportwissenschaftlichen Konzeptes in der Realität funktioniert (mit ebenfalls ca. 30% des Aufwandes). Ziel dieser Arbeit ist in dieser Ebene beispielhaft die folgenden Fragen beantworten zu können

Neben diesen formalen Fragen muß geklärt sein

Die Antworten lassen sich nicht a priori festlegen, da viele Fragestellungen aus der Situation heraus entstehen und sich vorher nicht absehen lassen. Das verleitet zum Datensammeln auf Verdacht und verschlechtert somit das Kosten - Nutzen - Verhältnis.

 

Konzeptebene

Hinter den verwendeten Konzepten stehen medizinische bzw. sportwissenschaftliche Überlegungen, die für eine konkrete Klasse von Fällen (z.B. die männliche Olympiamannschaft im Rudern) ein typisches Vorgehen beinhaltet. Das so formulierte Modell ist der Kern des Systems. Im Fall von "CTS" wurde dies von Mag. Werner Schwarz erarbeitet [Schwarz96], in einer früheren Fassung an die Arbeiten von Dr. Paul Haber [Haber84] angelehnt. Im jeweiligen Fall wurden sie dann den Anforderungen der jeweiligen Verbände bzw. Trainer angepaßt. Da diese Konzepte vorhanden sind bzw. von Experten beigestellt wurden und nur an die technologischen Möglichkeiten anzupassen waren, betrug der Anteil am Projektumfang nur ca. 10%.

 

Methodische Ebene

Dazu gehören zwei getrennte Bereiche:

  1. Aus Sicht des Benutzers:
  2. Die verwendete Methodik in der Bewältigung der Aufgabe, wie z.B. die Anwendung einer bestimmten Operationstechnik in der Medizin, aber auch die Integration der verwendeten Technik (u.a. der Software) in den Arbeitsablauf (s. [Hammer97c]).

  3. As Sicht des Herstellers:

Die Erstellung des Werkzeuges und dessen Funktionalität selber (ca. 30% des Aufwandes - mit der typischen Verteilung 40% - 20% - 40% für Design, Codierung und Test bzw. Wartung).

Der Inhalt dieser Arbeit wird sich naturgemäß hauptsächlich den technischen Belangen des Asgaard - Projekts widmen.

Zurück zum Inhalt

 

1.2.2 Rollenverteilung

Um ein Werkzeug zum Einsatz zu bringen, müssen auch die Rollen der potentiellen Benutzer klar definiert werden, da hier unterschiedliche Ansprüche an das Werkzeug formuliert werden. Der Gegenüberstellung zwischen der sportlichen (Abbildung 3) [Hammer97d] und der medizinischen Domäne (Abbildung 4), wird hier der Hauptaugenmerk gewidmet.

 

Administration

 

Patient

Im Gegensatz zum Sportler hat der Patient eine meist passive Rolle. Auch um die Qualität der aufgenommenen Daten zu sichern müssen viele Werte extern kontrolliert werden.

  

Arzt und Fachärzte

Hier ist der entscheidende behandelnde Arzt gemeint (der aber wechseln kann). Er ist der Hauptnutzer des Asgaard-Tools und soll in seiner Diagnose und Therapieplanung unterstützt werden.

Fachärzte haben nicht die gleiche Entscheidungsbefugnis wie der behandelnde Arzt. Sie sind "Zulieferer" von Teildiagnosen und erzeugen einen wesentlichen Teil der Datenmenge.

 

Pflegepersonal und Therapeut

Ihr Aufgabenbereich befaßt sich mit:

 

Experte (kann auch der Arzt sein)

Der Experte erzeugt aufgrund der gewonnen Daten und Erfahrungen neues Wissen, bzw. bringt neues Know-How in Form von klinischen Protokollen ein. Diese Tätigkeit ist meist nicht direkt an die Existenz eines bestimmten Patienten gebunden und kann dezentral erfolgen.

 

Fazit

Da die Daten dezentral und zu unterschiedlichen Zeitpunkten erfaßt werden sollen, muß die Datenbankstruktur dezentral (verteilt) sowohl on- als auch offline erfolgen können. Das Userinterface jedes Clients muß den jeweiligen Erfordernissen optimal angepaßt werden können - z.B. für die manuelle Erfassung bestimmter einzelner Werte, der Eingabe von Erkenntnissen (Diagnosen) oder dem automatischen Einspielen großer automatisch generierter Datenmengen.

Zurück zum Inhalt

 

1.2.3 Zielgruppen

Diese Arbeit orientiert sich an der medizinischen Anwendung von Asbru. Eine offene Architektur soll es aber im Prinzip ermöglichen, daß sehr unterschiedliche Zielgruppen angesprochen werden können. Die unterschiedlichen Ansprüche sollen durch spezifische Inhalte (Daten) und deren Darstellung abgedeckt werden, die grundlegenden Strukturen sollen aber offen für neue Inhalte bleiben. Spezialfunktionen zur Adaptierung an bestimmte Aufgaben sollen nachträglich integrierbar sein.

 

Abbildung 5 potentielle Zielgruppen

 

Das verbindende Thema der in (Abbildung 5) dargestellten Anwendungsgebiete ist der Umgang mit Wissen. Die vollen Striche markieren Problemdomänen, in denen wir praktische Erfahrung gesammelt haben. Know-How soll transportiert werden (Lehre - Pädagogische Komponente). Das Wissen soll eingesetzt werden, um Leistungsprozesse besser steuern zu können (existierende Werkzeuge - praktische Komponente). Letztlich soll aus den in der Praxis gesammelten Daten neues Wissen gewonnen werden (Forschung, neue Werkzeuge - wissenschaftliche Komponente). Im Unterschied zu gebräuchlichen Methoden, die dynamische Vorgänge nicht ausreichend terminisieren, ist Asbru eine intentions- (ziel-) und zeitbasierte Repräsentationssprache, die die Aquisitation und Ausführung von skeletalen Plänen (Rahmenplänen) ermöglicht.

Zurück zum Inhalt

 

1.3 Aufgetretene Probleme und Lösungsansätze

 

1.3.1 Soziologische Ebene

Die potentiellen Interessenten lassen sich grob in zwei Gruppen einteilen: (1) Jene, die sich bereits mit der Thematik beschäftigen und sich eine "selbstgebastelte" Lösung zugelegt haben. Um diese aufzugeben, muß der potentielle Nutzen gegenüber der existierenden Implementierung sehr hoch sein. (2) Die zweite Gruppe ist sich bewußt, daß das Gebiet wichtig für ihre Arbeit ist, hat sich aber (zumeist aus zeitlichen Gründen) noch keine Umsetzung mit dem Computer zugelegt. Bei dieser Gruppe ist die Kombination wenig Vorwissen, wenig Zeit und oft alte Software vorherrschend. Es muß deshalb

Entscheidend für den erfolgreichen Einsatz des Werkzeuges ist, ob es gelingt die Daten regelmäßig in konstanter Qualität zu erfassen, d.h. ob die verwendete Methodik in die Gewohnheit und Routine der Benutzer eingefügt werden kann. Da deren Zeit begrenzt ist, muß sich ein Rationalisierungseffekt gegenüber dem bestehenden System erzeugen lassen.

Zurück zum Inhalt

 

1.3.2 Kontextuelle Ebene

Der konventionelle Ansatz, der zu einzelnen Fragestellungen jeweils spezielle Statistiken erstellt, führt zur Problematik, die in "CTS" nur teilweise gelöst werden konnte:

Diese Probleme wurden gelöst, indem Daten von den Analysen getrennt und über eine Abfrage miteinander verbunden wurden. Die Datenstruktur kann vom Benutzer festgelegt werden und orientiert sich an einer effizienten Datenerfassung. Die Konstruktion der Abfrage ermöglicht es das für die Analyse notwendige Datenformat zu generieren. Die Entstehungsgeschichte wird jedoch nicht dokumentiert.

 

Die zentrale Erkenntnis aus dem "CTS" Projekt war, daß statistische Methoden nicht ausreichen, um die zentralen Fragestellungen zu lösen (siehe Kapitel 1.1.2 Seite *), da:

 

Um hier zu besseren Lösungen zu kommen, können Methoden aus der Artificial Inteligence (AI) eingesetzt werden - ein Ansatz, den Asgaard verfolgt. Dadurch kann

 Zurück zum Inhalt

 

1.3.3 Konzeptebene

Die sportwissenschaftlichen bzw. medizinischen Modelle sind größtenteils vorgegeben. Trotzdem gibt es auch hier Kritikpunkte

Diese Punkte sind um so wichtiger, da der Computer eine "Objektivität" suggeriert, die in Wirklichkeit nicht existiert. Im Gegenteil, durch den Einsatz der EDV werden Information aus dem Kontext herausgelöst und verlieren somit ihren natürlichen Inhalt [Weizenbaum90].

Andererseits ermöglicht moderne Informationstechnologie Methoden, die mit Papier und Bleistift nicht durchführbar sind. Es macht durchaus Sinn in einem ersten Schritt bestehende und bewährte Modelle anzupassen, bevor die Grenzen der Technologie ausgenutzt werden.

Zurück zum Inhalt

 

1.3.4 Methodische Ebene

Die wesentliche Eigenschaft bei "CTS" war die automatische Konsolidierung der replizierten Datenbank. Da jeder Benutzer seine Daten entsprechend seiner Rolle unabhängig von anderen eingeben konnte, wurde eine hohe Rationalisierung erreicht. Daraus resultierte aber eine Problematik, die noch nicht gelöst wurde:

 

Weitere Unzulänglichkeiten des "CTS" - Systems:

Um diese Probleme zu lösen, wollen wir vom traditionellen Weg immer mächtigere Programmpakete zu erzeugen, abgehen und die Möglichkeiten eines flexiblen HTML & Java Konzeptes zu verfolgen. Funktionalität soll in Form kleiner, kompakter Komponenten in Dokumente eingebunden werden. Dazu muß die Datenbank solch verteilte Objekte auch unterstützen.

 

In "CTS" fehlte auch:

Dadurch steigt entweder der Arbeitsaufwand, wenn alle Informationen erfaßt werden sollen, oder sie fehlen für eine Analyse. "Besondere" Daten in Kurzform müssen daher in einen (individuell definierten) "Datenkontext" eingebettet werden können, wobei sich dieser ändern kann.

Zurück zum Inhalt

 

1.3.5 Grenzen

Wie bereits angesprochen, muß auch festgelegt werden, was man sich von einem solchen Werkzeug nicht erwarten kann um damit erfolgreich umgehen zu können, um so mehr als der Computer eine Objektivität vortäuscht, die a priori nicht gerechtfertigt ist.

 

Analyse

In der abendländischen Kultur versuchen wir Wissen über das Ganze über das Verständnis der Einzelteile zu erlangen. Offensichtlich funktioniert diese Methode sehr gut, sie führt aber auch dazu, daß es uns oft in die Lage eines kleinen Kindes versetzt, das sein Spielzeug zerlegt hat und es ob der Fülle an Einzelteilen nicht mehr zusammensetzen kann. Dazu kommt, daß die Trennung einzelner Begriffe nicht immer durch das begründbar ist, was wir beobachten können nach Alfred Korzybiski [Jochim97]: Es gibt keine kognitiven Leistungen, die unabhängig von Gehirn und Nervensystem funktionieren könnte. "Körper" und "Geist" stehen in einer zyklischer Zusammenarbeit. Diese Trennung hat zu einer Medizinischen Wissenschaft geführt, die sich um den "Körper" kümmert und zu einer Psychologie, die den "Geist" behandeln will. Als Trainer bekommt man die Kluft zwischen Sportmedizin und -Psychologie besonders stark zu spüren, denn wenn es um die Entwicklung von Leistung geht, sind die Aussagen der Experten nie ausreichend, um fundierte Entscheidungen treffen zu können. Das Fehlende muß in gemeinsamer Arbeit zwischen Trainer und Athlet mit meist intuitiven Methoden ergänzt werden. Ein Werkzeug in diesem Prozeß muß also die Synthese unterschiedlicher Modelle ermöglichen ohne sie zu verwischen.

 

Modelle

Ein Modell ist immer eine Vereinfachung der Wirklichkeit, in der auf Details auf Grund der Verallgemeinerung verzichtet wird. Ein gutes Modell ist eines, das die zugrundeliegende Realität in ihren relevanten Strukturen gut abbildet. Korzybiski hat in seinem "neurolinguistischen Training" (NLT) solche Abbildungen mit Landkarten verglichen. Damit ist leicht nachvollziehbar, wann eine Karte gut und wann schlecht ist. In der Medizin (und auch der Sportwissenschaft) sind gewisse Bereiche gut erforscht und andere kaum. Wagt man sich nun in Themenkomplexe, in der sowohl gut- und schlecht erforschte Bereiche existieren entsteht eine verzerrte Landkarte, in der nicht sichergestellt werden kann, das die dem verwendete Modell zugrundeliegende Abbildung alle Bereiche entsprechend ihrer Bedeutung abbildet. Zudem liegen die entscheidenden Informationen in Details, die sich eben nicht in das Gesamtbild einfügen lassen. Schafft man es nicht diese in die Struktur des Modells zu integrieren, sinkt die Wahrscheinlichkeit ein optimales Ergebnis zu erreichen. Das mag z.B. für den Fitneßsport trotzdem ausreichen, in Intensivmedizin oder im Spitzensport kann man sich damit nicht zufriedengeben. Das Ziel beim Einsatz von Asgaard muß also ein Gesamtkonzept sein, das mit der Zeit immer schärfere Formen annimmt. Die Schärfe der Strukturabbildung ist dabei das entscheidende Gütekriterium.

 

Identität

Die uns gebräuchliche Logik geht auf Aristoteles zurück und basiert unter anderem auf der Identität zwischen einem Symbol und dessen, was es in der Realität repräsentiert. Wenn Begriffe, die in unserem Bewußtsein formuliert werden, auf dem individuellen Kontext des jeweiligen Nervensystems basiert, folgt daß die Bedeutung eines Begriffes von dem individuell Erlebten abhängt. Jeder Mensch "füllt" ein Symbol mit anderen Erlebnissen.

 

Ein Mann kommt in den Himmel und trifft einen Freund, auf dessen Schoß ein süßes Mädchen strampelt. "Wie himmlisch", sagt der Neuangekommene, "Ist sie Deine Belohnung?" "Nein", sagt der alte Mann traurig, "ich bin ihre Strafe."

aus einem Vortrag von Rupert Riedl

 

Die gleiche Realität wird offensichtlich sehr unterschiedlich wahrgenommen.

 

Sowohl die erfaßten Daten, als auch die von einem automatischen System gelieferten Resultate sind von mehreren Störgrößen beeinflußt, eine davon ist die oben geschilderte. Ein wissenschaftliches Modell, daß solche Störgrößen ignoriert ist in der Praxis nicht einsetzbar, da selbst wenn statistische Korrektheit nachgewiesen der Bezug zum konkreten Fall kaum herzustellen ist. Es ist das Dilemma jedes Trainers bzw. Arztes zu entscheiden, ob das Wissen, Testverfahren, Beispiel, ... beim eigenen Sportler bzw. Patienten anwendbar ist.

 

Fazit

Der Schwerpunkt in der erfolgreichen Umsetzung des Asgaard - Projekts liegen im kontextuellen Bereich. Für die integrierten Konzepte ist der jeweilige medizinische bzw. sportwissenschaftliche "state of the art" ausschlaggebend. Für die Umsetzung der verwendeten Konzepte in der Realität tragen aber wir die Hauptverantwortung, hier entscheidet sich die Effizienz von Asgaard. Ziel ist deshalb die Unterstützung des Arztes unter der Einbeziehung von medizinischen Know-Hows, aber eher als "Diskussionspartner" in Form einer intelligenten Datenbankschnittstelle, nicht um ärztliche Kompetenzen zu ersetzen.

Zurück zum Inhalt

 


2 Verwendetes Paradigma

Die Wahl des verwendeten Paradigmas beruht auf den im vorigen Kapitel beschriebenen Problemstellungen. Am Ende werden noch die diskutierten Alternativen dargestellt.

 

2.1 Planrepräsentation mit Asbru

 

"Therapieplanung und deren Umsetzung wird immer komplexer. Das mannigfaltige Wissen über die Krankheitsverläufe der Patienten, die verschiedenartigen Ziele und Intentionen des medizinischen Personal und die unterschiedlichen Rahmenbedingungen erschweren diesen Prozeß. Medizinische Leitlinien und Protokolle sollen die Durchführung therapeutischer Interventionen unterstützen. Zur Zeit sind diese Protokolle jedoch noch nicht in einer Form verfügbar, so daß sie unmittelbar zur (computerunterstützten) Therapieplanung verwendet werden könnten.

 

Ziel des Asgaard/Asbru Projektes ist die Entwicklung von Werkzeugen, die dem medizinischen Personal — den Ärzten — bei der Erstellung und Umsetzung komplexer Therapiepläne helfen. Einerseits entwickeln wir Werkzeuge, die während der Designphase die Protokollerstellung vereinfachen (z.B.: Verfikation und Validation von Protokollen). Andererseits entwickeln wir Werkzeuge, welche die Durchführung von Therapieplänen verbessern (z.B.: Erstellung von Therapieplänen und alternativer Plänen, Evaluation von Therapieplänen). Dabei werden Zielsetzungen und Methoden des Asgaard Projektes vorgestellt. Eine wichtige Voraussetzung für Umsetzung dieser Methoden ist eine geeignete Repräsentation von Protokollen: die zeitorientierte Sprache Asbru ermöglicht die Repräsentation von durativen Protokollen mit entsprechenden medizinischen Intentionen". [Miksch97a S.1]

Zurück zum Inhalt

 

2.1.1 Die Idee

Aufgrund von skeletalen Plänen ("clinical guidelines") und einer Bibliothek von realen Fällen wird wiederverwendbares Wissen gesammelt, das über eine "intelligente" Schnittstelle den agierenden Personen zur Verfügung gestellt wird. Der Mensch bleibt weiterhin die entscheidende Instanz, die Grundlage für die Entscheidungen soll aber durch die gesammelten Erfahrungen und Vorschriften bereichert werden. Die Patientendaten werden dazu mit in Frage kommenden skeletalen Plänen kombiniert und auf ihre Erfolgschancen hin untersucht. Aus einer Reihe von Alternativen wird ein Plan ausgewählt, der in seiner Durchführung verfolgt wird, ob die gesetzten Ziele auch weiterhin erreicht werden können.

 

Abbildung 7 das Asgaard Modell aus [Miksch97b

 

Dabei können Abläufe modelliert werden, die zu komplex sind, um etwa in einem Flußdiagramm dargestellt werden könnten. Gleichzeitig muß die Wissensbasis zur Bearbeitung eines Problems nicht vollständig sein. Aufgrund von Vorbedingungen und Zielen einzelner Pläne werden für einen konkreten Fall geeignete Pläne selektiert und zur Anwendung gebracht. Das agierende Personal (Abbildung 7) wird durch Vorschläge aus einer umfangreichen generischen Fallbibliothek unterstützt.

 

Einige wesentliche Eigenschaften von skeletaler Planrepräsentationen:

Zurück zum Inhalt

 

2.1.2 Planhierarchie

Asbru basiert auf einem hierarchischen Plankonstrukt, das Pläne aus anderen Plänen (Subpläne) zusammensetzt. Dabei können Pläne sequentiell, parallel zyklisch oder einige Pläne aus einer vorgegebenen Auswahl ausgeführt werden. Die Ausführung eines Planes kann (an ein technisches Aufgabenmodell angelehnt) gestartet, abgebrochen, unterbrochen oder beendet werden.

Plan

Abbildung 8 Planhierarchie

 

Ein Asbru-Plan (in [Miksch97a] in BNF-Form spezifiziert) beinhaltet neben dem Namen und einer Menge von Argumenten fünf zentrale Teile (Abbildung 8):

Zurück zum Inhalt

 

2.2 Java & JDBC

Java wurde 1995 von SUN Microsystems eingeführt und ist die erste und derzeit einzige Sprache, die für Inter- bzw. Intranetprogrammierung entwickelt wurde. In ihrem Sprachgebrauch ähnelt sie C++, ist aber einfacher [Gosling96].

 

Der Name Java kommt von der bei Programmierern sehr beliebten Kaffeemarke gleichen Namens, die auf der Insel Java hergestellt wird. Java wird jetzt von der Sun-Tochter JavaSoft weiterentwickelt und besteht aus drei Komponenten.

 

Java unterstützt eine Reihe von Klassenbibliotheken. Die für diese Arbeit wichtigste ist das JDBC–API (Java Database Connectivity-Application Programming Interface), welches auf einem niedrigen Niveau aufsetzt, nämlich ANSI kompatiblen SQL-2-Syntax (Structured Query Language). Es stellt eine Alternative zu dem (auf Windowssystemen) quasi – Industriestandard ODBC (Open Database Connectivity) dar, welcher mit speziellen Treibern ebenfalls unterstützt wird.

 

Mit Java lassen sich sowohl Applets, das sind Programme, die in ein HTML Dokument eingebettet sind und innerhalb eines WWW-Browsers mit restriktiven gehandhabten Ressourcen gestartet werden, als auch eigenständige Applikationen erzeugen. Die wichtigsten Eigenschaften sind:

Zurück zum Inhalt

 

2.2.1 Systemkomponenten

In konventionellen Systemen ist eine zweischichtige Client-Server Architektur (Abbildung 9) üblich.

 

Abbildung 9 2-schichtige Architektur

 

Java benötigt aber aufgrund seiner Konzeption zur plattformunabhängigen Netzwerkapplikation mehrere verteilte Komponenten um zu funktionieren:

 

Die räumliche Lokaliatät der einzelnen Komponenten (ein oder mehrere Rechner) ist im Entwurf nicht bedeutend, hat aber auf Performance, Flexibilität und Skalierbarkeit durch Ladezeiten und Kommunikationswege enormen Einfluß. Um der Intention von Java der Plattformunabhängigkeit zu folgen ist auch die Lokalität von native-Code zu berücksichtigen. Da irgendwann eine reale Datenbank eingesetzt werden muß, wird man spätestens bei der Wahl der Treiber mit diesem Problem konfrontiert werden.

Zurück zum Inhalt

 

2.2.2 Systemarchitektur

Die im folgenden dargestellte Konzeption ist eine von mehreren möglichen, die sich in Java jedoch durchgesetzt hat. [Dicken97 S.58ff] In dem gewählten Modell (Abbildung 10) werden die notwendigen Komponenten in drei funktionalen Schichten gruppiert.

 

Abbildung 10 3-Schichtmodell nach [Dicken97]

 

  1. Schicht besteht aus dem Datenbankserver in dem das Datenmodell implementiert wird und dem Web-Server, eventuell auf unterschiedlichen Hosts.
  2. Schicht bildet eine "Middleware", und soll die Verwendung eventuell vorhandenen native-Code, Datenbanktreiber u.ä. ermöglichen, außerdem läßt sich die Datenaufbereitung und Vorbereitung der Präsentation auslagern.
  3. Schicht ist der Client, wobei zwischen einen administrativen Client (z.B. zur Verwaltung der Zugriffsrechte u.ä.) und einem operativen Client unterschieden werden kann. Durch die Middleware kann dieser Client sehr schlank gehalten werden, was der Performance, aber auch dem "100% pure Java" Gedanken nahekommt. Weiters lassen sich Clients auch für leistungsschwache "hand-held" PCs implementieren, was unsere Zielgruppe (Arzt am Krankenbett) sicher gutieren wird.

 

Anm.: Die in Abbildung 10 nicht farblich unterlegten Teile ("stored procedures", "DB-Client" und "Servletts" sind jene Komponenten, die in dieser Arbeit zu implementieren wären.

 

Vorteile der 3-Schicht Architektur:

 

Nachteile

 

Die Verwendung von "Stored Procedures" und "Servletts" vereinfacht die Kommunikation zwischen Client und Serverkomponenten. Servletts sind serverseitige Appletts, die einmal gestartet im Speicher geladen bleiben. Sie erfüllen die Funktion von HTML-Scripts wie z.B. Perl. Da sie normalerweise keine GUI Elemente benötigen, laufen sie fast mit native Code Performance – alle in der selben "Virtual Machine", deshalb entfallen die z.B. in Perl nötigen Task-Switches. Außerdem minimieren sie die Prozesskomminikation über RMI (ab dem JDK 1.2 alternativ auch CORBA) und vereinfachen den Ressourcenzugriff und die Handhabung der Java-Schutzmechanismen. Voraussetzung ist der Einsatz eines Webservers mit einer Java Virtual Machine wie z.B. der JavaServer von JavaSoft.

Zurück zum Inhalt

 

2.2.3 Datenbank-Treiber

JavaSoft [Dicken97 S.68] unterscheidet 4 unterschiedliche Kategorien von JDBC-Treiber:

  1. ODBC-Bridge Treiber (Typ 1 Treiber). Dabei wird der JDBC Aufruf in ODBC Aufrufe umgesetzt. Die Java-Schicht ist sehr dünn und reicht Aufrufe nur durch. Die Existenz von nativen ODBC-Treibern auf der Maschine sind Voraussetzung.
  2. Native API Partial Java-Treiber (Typ 2 Treiber). Diese übersetzen JDBC Aufrufe in ihre native Datenbank-API. D.h es kommen die herstellerspezifischen Datenbankmethoden zum Einsatz.
  3. Net Protocol All-Java-Treiber (Typ 3 Treiber). Die JDBC Treiber sind komplett in Java geschrieben und werden vom Client mitgeladen. Der Client nimmt Kontakt zum Server auf, der die Aufrufe in native Datenbankaufrufe umsetzt.
  4. Native Protocol All-Java-Treiber (Typ 4 Treiber). Hierbei kommuniziert der Treiber über das Netz direkt mit dem Datenbankserver unter Ausnutzung der nativen Netzwerk-Protokolle. Der Treiber kann sowohl im Application-Server als auch im Client geladen sein.

 

Das Laden der Treiber zum Client wird nicht von jedem Browser erlaubt. Insgesamt legt die Struktur der Treiber eine Konzeption eines 3-schichtigen Modelles (z.B. in Form von Servletts am WWW-Server) nahe, da falls nur Typ 1 oder 2 Treiber verfügbar sind diese ansonst vor dem Starten des Clients lokal installiert werden müßten, was einerseits ein aufwendiger Vorgang ist und andererseits der Intention von Java widerspricht. Ein weiteres Argument für dieses Modell sind per-Client Lizenzen für Treiber und native-Components die so vermieden werden.

 

Der Performance Unterschied liegt bei +160% (1000Querys) bis +310% (100Querys) von Typ 4 (besser) gegenüber Typ 1 Treiber (schlechter) in Abhängigkeit von der Anzahl der Querys [Dicken97 S.356].

Zurück zum Inhalt

 

2.3 Alternativen

Der Ausgangspunkt dieser Arbeit lag eigentlich mehr im Bereich der Datenanalyse in einer sportlichen Problemdomäne. Das Projekt "CTS" hat aber gezeigt, daß die Voraussetzungen für eine fundierte Datenanalyse fehlen:

 

Mag der erste Punkt im klinischen Kontext keine große Rolle spielen, so hat sich doch gezeigt, daß für die Akzeptanz der angestrebten Analysemethoden der Benutzer so gut in seiner Arbeit unterstützt wird, daß

Zurück zum Inhalt

 

2.3.1 Adaptive Algorithmen

Ursprünglich stand zur Diskussion, lediglich die statistischen Funktionen von "CTS" um adaptive Algorithmen wie z.B. "Neuronale Netze" und "Genetische Algorithmen" zu erweitern und den Einsatzbereich der einzelnen Methoden zu untersuchen.

 

Adaptive Algorithmen

Asbru

+/- Je größer die Datenmenge desto besser funktionieren sie

+ Toleriert unscharfe Werte und ungenaue Testmethoden

+ Funktioniert auch bei unvollständigen Wissen über die Problemdomäne

- Benötigt für das Training der Algorithmen einen Experten

+ Funktioniert auch bei großen Datenmengen

+ Im Routinebetrieb ist kein Experte notwendig

+ Ermöglicht die laufende Erweiterung der Wissensbasis einer Problemdomäne

- oft stehen nur "unscharfe" Werte zur Verfügung, mit denen das System nur schwer umgehen kann

 

Abbildung 11 Alternative im methodischen Ansatz

 

Die leichtere Handhabung von Asbru durch den Benutzer in Kombination mit der Möglichkeit Wissen zu sammeln und wiederzuverwerten hat den Ausschlag für die formale Methode gegeben (Abbildung 11). Dadurch änderte sich auch die Richtung dieser Diplomarbeit mit einer Ausweitung auf die medizinisch Problemdomäne. Dafür muß leider auf das akademisch reizvolle Thema über den Umgang mit großen Mengen unscharfer Information verzichtet werden.

Zurück zum Inhalt

 

2.3.2 Gewählte Sprache

Prämisse bei der Wahl der Sprache war eine leichte Portierbarkeit und die Verfügbarkeit von Humanressourcen. Eine weitere Alternative wie z.B. CLIPS [Giarratano94] schied aus diesen, aber auch technischen Gründen aus. Zielrichtung ist ein homogenes Produkt, das möglichst komplett in einer Umgebung erstellt werden kann.

 

C++

Java

+ Objektorientierung

+ mächtige, weit verbreitete Sprache mit vielen Sprachkonstrukten

+ es sind umfangreiche stabile Klassenbibliotheken verfügbar

- sprachbezogene Sicherheitslücken, fehlende Netzwerkunterstützung

- nicht portabel (plattformabhängige Klassenbibliotheken)

+ Objektorientierung

+ Plattformunabhängigkeit durch die Interpretation von Bytecode

+ Robustheit durch moderne Mechanismen wie Exception Handling, Multithreading

+ Eingebaute Sicherheitsmechanismen von Ressourcen und Netzwerkdesign

- Langsam durch die Interpretation von Bytecode

 

Abbildung 12 Wahl der Entwicklungsumgebung

 

Die Entscheidung für Java fiel aufgrund der Java-spezifischen Eigenheiten gegenüber anderen Sprachen (Abbildung 12), also Plattformunabhängigkeit, Robustheit und Netzwerkdesign. Der Preis dieser neuen Sprache sind noch nicht etablierte Standards, wie z.B. RMI und teilweise instabile Klassenbibliotheken.

Zurück zum Inhalt

 

2.3.3 Gewählte Datenbank

Als Alternative stand eine komplett objektorientierte Implementierung, also auch mit einer objektorientierten Datenbank zur Diskussion.

 

Objektorientierte DB (OODB)

Relationale DB (RDBMS)

+ keine aufwendige Modellierung und Administration eines Datenbankmodells notwendig

+ Umsetzung eines modernen, homogenen Konzepts

+ sehr gute Erweiterbarkeit

- Es gibt derzeit noch keine Unterstützung für OODBs durch JDBC

+ Bekannte Problematik und Performance

+ Gute Unterstützung durch Java mit JDBC und guter Support durch die Hersteller

+ Weite Verbreitung und verfügbare Humanressourcen

- eine aufwendigere Administration des Datenmodells ist notwendig

Abbildung 13 Alternative im Datenmodell

 

Die Möglichkeiten von Java-JDBC haben gemeinsam mit den in der Projektgruppe verfügbaren Know-How den Ausschlag für RDBMS gegeben (Abbildung 13). Die aufwendige Administrierung des Datenmodells soll mit einem geeigneten Konzept abgefangen werden.

Zurück zum Inhalt


3 Anforderungen

In diesem Kapitel sollen die grundlegenden Anforderungen analysiert und eine Prozeßmodellierung des Asgaard-Projekts durchgeführt werden.

 

3.1 Zieldefinition

3.1.1 Thema

Das Thema ist die intelligente Unterstützung von gezielten Eingriffen in komplexe biologische Prozesse durch medizinische Therapie, Rehabilitation oder Training. Dabei sollen die agierenden Personen durch den interaktiven Zugang zu einer umfangreichen Bibliothek an gelösten Fällen von gesammelten Wissen effizient unterstützt werden.

 

3.1.2 Erfolg

Wir definieren Erfolg über die "Kundenzufriedenheit", mit anderen Worten den Anwenderkomfort oder wie weit wir den potentiellen Markt erschließen können. Andere Merkmale, wie Funktionsumfang oder Qualität orientieren sich an diesem Prinzip. Wir wollen deshalb

 

ein Programm schaffen, welches in der medizinischen bzw. sportlichen Praxis verwendet wird und die jeweilige Arbeit unterstützt.

 

Der Anspruch wissenschaftlich neue Konzepte zu erarbeiten oder neue Maßstäbe in der technischen Umsetzung zu setzen ist unser Ehrgeiz, muß sich aber dem oben gesteckten Ziel unterordnen.

Zurück zum Inhalt

 

3.1.3 "Unique Selling Point"

Drei wesentliche Eigenschaften zeichnen das geplante System aus:

 

  1. Die Kommunikation zwischen den beteiligten Personen (Ärzte, Patienten, Pflegepersonal bzw. Sportler und Trainer) wird unterstützt und genutzt. Die anfallenden Daten werden als "Nebenprodukt" dieser Kommunikation einer weiteren Verwertung zugeführt, wodurch ein Mehraufwand möglichst vermieden wird.
  2.  

  3. Es wird a priori keine inhaltliche Struktur vorgegeben. Jedes medizinische oder sportwissenschaftliche Modell kann abgebildet und in der Praxis eingesetzt werden. Speziell Asbru ermöglicht eine beliebige Skalierung von Wissen durch die Verknüpfung von immer mehr exemplarischen oder gelösten Fällen
  4.  

  5. Der Versuch, Funktionalität, wie sie Analysen mit Asbru darstellen in den Kontext (die Realität) einzubinden und (noch) nicht beteiligten Personen zugänglich zu machen (z.B. Schulung). Dokumentation wird somit zu einem tragenden Produkt im jeweiligen medizinischen bzw. sportlichen Prozeß.

 Zurück zum Inhalt

 

3.1.4 Zielsetzung

Die Aufgabe dieser Diplomarbeit ist einen Datenbankprototyp zu erstellen, um

 

  1. Daten verfügbar zu machen und

 

  1. ein Werkzeug verwendbar machen, das

 

  1. eine sukzessive Integration zunehmend mächtigerer Anwendungen zu erlauben

Zurück zum Inhalt

 

3.2 Arbeitsablauf

Jede Tätigkeit hat drei wesentliche Phasen: Eine Vorbereitungsphase in der Ziele gesteckt werden und Überlegungen stattfinden wie diese Ziele erreichbar sind, die Durchführung der geplanten Aktivität und die anschließende Überprüfung, ob die gesteckten Ziele erreicht wurden. Letztendlich geht dieser Prozeß in sich selbst über und wiederholt sich ständig wie ein sich drehendes Rad.

 

Mit Asgaard / Asbru werden alle drei Bereiche konstruktiv unterstützt: Bereits in der Planungsphase werden aufgrund der bisherigen Erfahrungen die Erfolgschanchen einer Strategie bewertet und erfolgsversprechende Alternativen aufgezeigt.

 

Während der Durchführung wird einerseits laufend kontrolliert, ob die erwarteten Effekte auch tatsächlich eintreten, andererseits sollen die Pläne entsprechend adaptiert werden. Die Erkenntnisse, die aus der Gegenüberstellung von Plan und Wirklichkeit resultieren, fließen wieder in das System ein (Abbildung 14). Der rote Pfeil symbolisiert das direkte Feedback, das die Durchführenden während ihrer Tätigkeit bekommen.

Abbildung 14 Planung als Prozeßmodell

 

Asbru / Asgaard [Miksch97b] kann menschliche Intelligenz nicht ersetzen, es soll vielmehr bei Routinetätigkeiten in Planung, Kontrolle und Analyse unterstützen. Gleichzeitig ist es eine Bibliothek an Erfahrungen, die in einem "intelligenten" Dialog mit dem Benutzer Wissen zugänglich macht und ihm ein sofortiges Feedback in der Ausführung seiner Tätigkeit liefert.

 

Die Umsetzung der Planung und der Dokumentation erfolgt in Asbru mit Protokollen, die jeweils wieder aus beliebig vielen Protokollen bestehen können. Es gibt drei typische "Füllstände" mit Informationen der Protokolle, die sich in ihrer Aufgabe wesentlich unterscheiden aber auf den gleichen inhaltlichen Strukturen aufbauen:

 

 

Dieser mehrschichtige Aufbau - sowohl z.B. die Planung in Vorbereitung und Design zu unterteilen, als auch die verschiedenen Planungs- und Protokollebenen haben den Sinn Information wieder zu verwenden (und nur einmal einzugeben): Bekanntes soll übernommen werden, lediglich Neues wird geändert. So soll z.B. am Ende nur mehr eine geänderte Dosierung dokumentiert werden müssen ohne den restlichen (üblichen) Vorgang aufzuzeichnen.

Abbildung 15 Einsatz von Asbru

 

Die drei wesentlichen Phasen Planung-, Durchführung und Analyse haben eine Unterstruktur (Abbildung 15):

 

Planung

Konzeption: Vorbereitung grundlegender Strukturen

Design: Generische Pläne erzeugen

Exekution

Individualplanung: einen zu exekutierenden Plan erzeugen 

Analyse

Rückführung des Erkenntnisgewinnes

 

Der gesamte Prozeß wird durch Asbru unterstützt:

 

Bevor es jedoch zu solch einem Prozeß kommt, muß die Zielrichtung festgelegt werden um zu vermeiden, daß "ich zwar nicht weiß wohin ich will, dafür aber schneller dort bin".

 

Konzeption

Als vierte (oder besser erste) Phase muß folgende Fragestellung beantwortet werden:

 

Die angesprochene automatische Überprüfung von Protokollen und Wissensgenerierung ist Forschungsziel des Projekts und in seiner Zielsetzung in Kapitel 3.3 S.* genauer spezifiziert.

Abbildung 16 Arbeitsablauf mit Asgaard

 

Zwei Vorgänge sind hier verkoppelt (Abbildung 16): eine kontinuierliche Rückkopplung von Adaptierung der Planung und Durchführung in der Realität, der in größeren, periodischen Intervallen globale Analyse- und Planungsschritte gegenüberstehen.

 

Ziel ist es dabei Arbeit und Zeit zu sparen (Rationalisierung), Know-How zu transportieren (Pädagogische Komponente) und die Erreichbarkeit der Zielsetzung zu verfolgen (Steuerung). (Was aber nicht heißt, daß der Erfolg "programmiert" werden kann.)

 

Eine formale Analyse der Arbeitsvorgänge mit Hierarchiediagrammen ist im Anhang (siehe Kapitel 6.1 S.*) dargestellt.

Zurück zum Inhalt

 

3.3 Taskstruktur von Asgaard

Das Kernstück des Asgaard Projekts ist folgendes Set an Aufgaben nach [Miksch97d], die für die Umsetzung von protokollbasierter Therapieplanung notwendig sind. Phase 1 bescheibt dabei jene Module, die für einen kompletten Prototypen unbedingt notwendig sind (Abbildung 17), in Phase 2 weiterführende Aufgaben beschrieben (Abbildung 18).

Abbildung 17 Aufgaben in Phase 1

Die weiterführenden Aufgaben werden strukturell vorgesehen, sind aber noch nicht Teil der momentanen Implementation. Ziel der momentanen Phase des Asgaard - Projekts ist einen funktionstüchtigen Prototyp herzustellen, mit dem praktische Erfahrung in der Problemdomäne gesammelt werden soll.

Abbildung 18 weiterführende Aufgaben aus Phase 2

 

In dieser Arbeit soll eine Datenstruktur implementiert werden, auf die in erster Linie die Tasks der Phase 1 (Abbildung 17), aber grundsätzlich auch jene der Phase 2 (Abbildung 18) umgesetzt werden können.

Die bisher formulierten Tasks orientieren sich an der Erstellung und Exekution von Protokollen. Die hier definierten unterstützenden Tasks definieren den Zufluß und die Bearbeitung von Echtdaten zu den Protokollen zur Laufzeit

Abbildung 19 unterstützende Tasks

Mit dieser Vorverarbeitung, die eng an die Erfassung der Informationen gekoppelt ist, soll einerseits die Qualität der erfaßten Daten erhöht werden, indem der Person, die für diesen Vorgang verantwortlich ist ein umittelbares Feedback zu ihrer Arbeit geliefert wird, andererseits wird die Protokollverarbeitung dadurch entlastet.

Zurück zum Inhalt


4 Design

Die Konventionen der verwendeten Designmethoden richten sich nach [Pomb93] und werden durch die in den Anhängen dargestellten detaillierten Dokumenten vervollständigt. Die sprachspezifischen Inhalte sind in [Deitel97] enthalten, die Java und die Klassenbibliotheken des JDK beschreiben. Die formale Spezifikation von Java befindet sich in [Gosling96] genauso wie etliche White Papers. Die Internas der JDBC Schnittstelle sind in [Dicken97], [JDBC] sowie in [Oracle] beschrieben.

 

Um die Fertigstellung des Prototypen, der auf dieser Diplomarbeit beruht in endlicher Zeit zu gewährleisten ihn aber trotzdem detailliert zu spezifizieren, sind folgende Prioriätsstufen festgelegt:

 

Prior. A notwendige Funktionalität, muß implementiert werden (Default).

Prior. B wichtige Funktionalität, soll implementiert werden.

Prior. C wünschenswerte Funktionalität, kann implementiert werden.

 

Welche Teile tatsächlich enthalten sind, ist der Source-Dokumentation der jeweiligen Software-Release zu entnehmen.

Zurück zum Inhalt

 

4.1 Systemmodell

Die Grundlage für das gewählte Modell bilden

Das in Kapitel 2.2 "Java & JDBC" auf Seite * vorgestellte Systemmodell.

Das in Kapitel 3.3 "Taskstruktur von Asgaard" auf Seite * eingeführte Taskmodell.

Die in Anhang 6.1 "Hierarchien (Arbeitsvorgänge)" auf Seite * spezifizierten Arbeitsabläufe.

 

4.1.1 Funktionale Gruppierung

Dabei lassen sich in den unterschiedlichen Arbeitsschritten mehrere voneinander unabhängige Arbeitsvorgänge identifizieren. Je nach Größe des Einsatzgebietes (eine Arztpraxis bis hin zu einem Krankenhaus mit einer hohen Arbeitsteilung) sollen diese Arbeitsschritte sowohl in einem aber auch in mehreren Clients aufteilbar sein, indem man die entsprechenden Java-Klassen in einer bzw. mehreren Applikation(en) arrangiert.

 

Administration (Sekretär, Schwester)

 

Konzeption und Design (Experte für die entsprechende Domäne)

 

Auslösung der Durchführung (Arzt, Trainer) – ("Individualplanung")

 

Durchführung (Durchführendes Personal und Betroffene)

 

Bei der Durchführung sollte die Erstellung von "thin-Clients" möglich sein um mit Hand-held PCs arbeiten zu können. Falls das Gerät vor Ort (nicht im Krankenhaus) eingesetzt werden muß, sollte ein "abgespecktes" System für die betroffenen und vorbereiteten Fälle auch offline (d.h. mit einer lokalen Datenbank) erfolgen können.

 

Analyse (Experte)

Zurück zum Inhalt

 

4.1.2 Datenbank - Metamodell

Das Vorpojekt "CTS" hat gezeigt, daß die Anzahl der Tabellen rasch ansteigt, und eine effiziente Verwaltung notwendig ist, ohne daß ein eigener Administrator angestellt werden soll, der das erledigt. Um mit a priori unbekannten Datenstrukturen umgehen zu können, müssen Informationen von allen in der Datenbank vorkommenden Daten und den darauf operierenden Zugriffsfunktionen, wie z.B. Abfragen vorhanden sein. Die Datenbank muß also ein komplettes Modell ihrer Selbst beinhalten. In Folge werden die dem Benutzer zugänglichen Einheiten aus Daten, Struktur und Funktionalität "Datenobjekte" genannt, wenngleich es sich nicht um eine Datenbank im objektorientierten Sinn handelt.

 

Da für jede Klasse von "Datenobjekten" ein eigenes API, bzw. eine Komponente nötig ist um diese zu manipulieren, folgt eine Auflistung, die im Kapitel 4.2.4 (S. *) genauer spezifiziert werden.

 

Eine weitere Erkenntnis aus dem CTS-Projekt ist, daß eine Präsentation von Daten alleine nicht ausreicht. Soll über einen "Fall" (Patient, Sportler) diskutiert werden so bedarf es einer zusätzlichen verbalen Erläuterung. Das heißt Daten, eingesetzte Asbru-Pläne, Entschlüsse müssen in ihrer Entstehungsgeschichte dokumentiert und beschrieben sein. Solch eine "Diskussion" ist z.B. nötig, wenn ein Arzt durch einen anderen vertreten wird und dieser einen raschen Überblick über die Krankengeschichte bekommen muß, oder in der Ausbildung aber auch in der Analysephase wenn Daten mit der Realität in Bezug gesetzt werden müssen. Das berührt die in Kapitel 1.3.5 "Grenzen" auf Seite * dargestellten Probleme, die auch mit Asbru nicht vollständig gelöst werden können – nämlich die systembedingte Trennung von Daten aus ihrem Kontext in der Realität. Eine "Krücke" ist die Einbettung der Daten, Pläne usw. in eine verbale geschichtliche Darstellung (in Form eines Hypertextdokumentes) in dem auch auf weitere Daten (z.B. Röntgenbilder) verwiesen werden kann.

 

Dokumente

Eine Datenmenge soll dem Benutzer als "Dokument" präsentiert werden. Ein Dokument besteht aus mehreren Seiten, die gleicher oder unterschiedlicher Art sein können. Eine Dokumentseite ist zur Auswahl einer der Datenmenge (egal ob Replikation/Datenexport, Ansicht in einem Dokument für eine statistische Berechnung oder Exekution eines Asbru-Protokolles) die kleinstmögliche Einheit.

 

Ein Dokument soll mehrere Darstellungsformen haben:

Das Dokument kann gleichzeitig als "Operationsmenge" für den Benutzer, z.B. für Datenexport, Copy/Paste, Löschen, Exekution von Asbru-Protokollen, Ausführung von statistischen Auswertungen verwendet werden. Dazu muß sie aus der Gesamtmenge an Information nach unterschiedlichen Kriterien "herausgefiltert" (für eine/mehrere Personen, zeitlicher Kontext, ...) werden können. Solch eine Datenmenge soll dann einfach z.B. mit einem Asbru-Protokoll verknüpft in einer Dokumentseite (oder "standalone") eingefügt werden können.

 

Dokumentseite

Eine Dokumentseite enthält die kleinste zusammengehörige Menge an Daten und kann mehrere Sets an Inputdaten (z.B. in Form von Eingabeformularen), statistischen Auswertung von Daten (z.B. als Chart, die sich aber nicht nur auf die Daten der aktuellen Seite beschränken), Wisseninput in Form von Asbru-Code (Editor) und visualisierte Ergebnisse von Asbru-Exekutionen enthalten. Zwischen UI-Komponenten, die diese Aufgaben erfüllen soll editierbarer Text (HTML) mit Links auf andere Dokumentseiten, Multimediadaten einfügbar sein - z.B. um Interpretationen durch den Arzt bzw. Trainer festzuhalten und zu begründen.

Zurück zum Inhalt

 

4.1.3 UI-Komponenten

Der Schwerpunkt dieser Arbeit liegt bei der Erstellung der Datenbank und eines entsprechenden APIs. Für die Verwaltung der Datenbankobjekte müssen jedoch einige spezielle UI-Komponenten bzw. deren Funktionalität spezifiziert werden, die von der Struktur des gewählten Datenmodells berührt werden. (Siehe Kapitel 4.2 "Datenmodell" ab Seite *)

 

Datenobjektnavigator

Die rein administrative Verwaltung von Datenobjekten kann in Form von entsprechenden "Karteiblättern" erfolgen, welche die jeweilig spezifizierten Attribute abbildet. Wichtig ist, daß man Datenobjekte in mehreren unabhängigen hierarchischen Strukturen typübergreifend organisieren kann. Diese Struktur kann dann weiterverwendet werden.

 

Beispiel: An einer bestimmten Stelle der Dateneingabe die Auswahl verschiedener Begriffe zu gestatten. Die Zuordnung welche das sind, erfolgt über den übergeordneten Begriff:

 

Darüber hinaus sollen über diesen Navigator rasch auf Daten einer Person zugegriffen werden können. Diese Person ist dann z.B. einer (oder mehreren) Gruppe(n) zugeordnet, über die man sie finden kann. Dieser Zugriff soll in Folge die gesamte Krankengeschichte oder nur einen bestimmten Teil betreffen.

 

In diesem Navigator werden in gleicher Art Asbru-Pläne verwaltet und hierarchisch organisiert. Da ein Plan ja mehrere Instanzen hat (zumindest ein skeletaler Plan und eventuell mehrere tatsächlich verwendete Pläne in unterschiedlichen "Füllständen" mit Echtdaten) sollen auch hier in Folge auf eine Auswahl zugegriffen werden können.

 

Datenerfassung und Planeingabe

Um das Datenmodell nutzen zu können, müssen erfaßte Werte bzw. Pläne eng mit den definierten Datenobjekten verknüpft werden. Diese stellen einen zentralen Datentyp dar. Die darüber hinausgehenden Forderungen orientieren sich an einer effizienten Datenerfassung vor Ort, die auf unseren Beobachtungen im Zuge des CTS-Projekts erfolgten:

 

Die visuelle Erstellung und Manipulation von Asbruplänen nach [Kosara98] sind um einiges weitgehender als bloße syntaktische Erfassung – und macht diese eigentlich unnötig. An manchen Stellen des Arbeitsablaufes macht es aber durchaus Sinn nur eine kurze "Notiz" im Sinne von Asbru machen zu können, z.B. "Spritze X 200ml verabreicht" oder "5 mal 30m Sprint mit Tiefstart und 5min Pause" im sportlichen Kontext, bei dem eine grafische Eingabe eventuell umständlicher wäre. Diese Daten mögen manchmal als Formular vordefiniert werden, in einer Therapie (man denke an Rehabiltation) oder im sportlichen Training erfüllt nur eine syntaktische Eingabe die Forderung an ausreichende Flexibilität.

Zurück zum Inhalt

 

4.2 Datenmodell

4.2.1 Datenfluß

 

Als Verbindung zwischen Taskmodell und den Datenmodell ist folgendes Datenflußdiagramm (Abbildung 20) gedacht, es sind nur Tasks der Phase 1 (Abbildung 17 S.*) angeführt:

Abbildung 20 Datenfluß mit Asbru

 

Wie man an den beiden "Zeitschienen" im Arbeitsablauf (siehe Abbildung 16 S.*) erkennen kann, sind zwei grundsätzlich unterschiedliche Ansätze im Umgang mit der anfallenden Information gegeben:

 

Die syntaktische Repräsentation von Zeit, wie sie in Asbru spezifiziert ist, bleibt davon unberührt. Es geht lediglich um Organisation der anfallenden Datenmengen. Bereits aus dem Arbeitsablauf, aber auch aus Überlegungen der Wiederverwendbarkeit von Plänen und Rohdaten erscheint eine Trennung von Wissen (in Form von Plänen) und Informationen (in Form von Rohdaten) sinnvoll.

 

Bei der Verarbeitung der Daten sind deshalb folgende Szenarien möglich (Abbildung 21):

 

Abbildung 21 Anwendungszenerien

Aufgrund der vorliegenden Daten werden einige skeletale Pläne ausgewählt und mit diesen Daten durch den Exekutor simuliert. Aufgrund dieser Simulation werden verwendbare Pläne den agierenden Personen vorgeschlagen, die dann einen Plan auswählen und durchführen (oder nicht durchführen). Die durchgeführten Pläne werden mit den tatsächlichen aufgetretenen Daten gespeichert.

 

Datenbankfunktionen

Aus diesem Diagramm lassen sich folgende Funktionen ableiten:

 

Aus dem hierarchischen Plankonzept von Asbru ergibt sich die Forderung

 

Aus Arbeitsablauf ergibt sich die Forderung nach

 

Daten

Um die beschriebenen Aufgaben wahrnehmen zu können, sind die Daten in drei Ebenen strukturiert (Abbildung 22):

Abbildung 22 Datenschichten

 

Echt- und Plandaten ("Inputdaten")

Sie werden vom Benutzer, Geräten oder vom Exekutor geliefert und werden normalerweise nicht geändert und wenn, dann nur vom Erzeuger (Autor). Bei der Erfassung/Änderung werden zeitliche (Geltungszeitraum), personelle (Autor, Patient/Sportler) und Kontextbezüge (Ort, Projekt, Test- bzw. Diagnosemethoden) hergestellt.

 

Datenlinks

Stellt die Verbindung zwischen Daten und einem Asbru-Protokoll dar, im allgemeinen Fall zwischen verschiedenen Entitäten, die Daten beinhalten. Sie wird über Relationen von verschiedenen Instanzen zwischen "Datenobjekten" (siehe Kapitel 4.2.4 S.*) realisiert.

 

Asbru-Protokolle

Mit den Protokollen wird Wissen in Form von skeletalen Plänen gesammelt. Berechnungsergebnisse des Exekutors können wieder Inputdaten erzeugen. Wichtig ist, daß ein Asbru-Protokoll mit unterschiedlichen Echtdaten (der gleichen Struktur) ausgeführt werden kann.

 

Dokumentseite

Diese Teile werden in "Seiten" organisiert, die dem Benutzer eine zusammengehörige Einheit präsentiert. Dadurch sollen einerseits verschiedene "Datenobjekte" wiederverwendet werden können (d.h. in mehreren Seiten vorkommen können) und zusätzliche (z.B. verbale) Erläuterungen enthalten, die den Bezug zur Realität dokumentieren.

Zurück zum Inhalt

 

4.2.2 Datenoperationen

 

Datenreplikation

Die Datenbank soll replizierbar sein, [Coulouris94 S.311ff] dahinter stehen die Überlegungen:

 

Problembereiche, die damit verbunden sind:

 

Repräsentation des UI

Für eine Dokumentseite muß dessen Einstellungen (Seiten - Layout, enthaltene UI-Komponenten + Layout + Datenmenge (= Link auf eine Dokumentauswahl)) und den füllenden HTML-Code enthalten. Dazu muß folgende Funktionalität gewährleistet werden:

 

Datenvorverarbeitung

Bis die Daten in einem Asbru-Protokoll verarbeitet werden, müssen sie einen mehrstufigen Selektionsprozeß durchlaufen, die aber nicht mehr Teil des Datenbanklayers sind. Die dafür notwendige Funktionalität ist auf mehrere Schichten verteilt. Da aber auch bei den jeweiligen Arbeitsschritten Informationen anfallen, müssen auch diese in der Datenbank untergebracht werden können:

 

Syntaxcheck:

Abstraktion

Validierung

Zurück zum Inhalt

 

4.2.3 Datentypen

Dazu müssen die in Abbildung 22 (S.*) eingeführten drei Schichten genauer betrachtet werden (Abbildung 23). Die Datenlinks sind wieder als Pfeile dargestellt, die gestrichelte Linie bezeichnet die Grenze des Datenbanklayers.

 

Abbildung 23 Datenfluß in den unterschiedlichen Layern

 

Inputdaten

Sind Daten, die für Asbru-Protokolle und Auswertungen herangezogen werden. Es gibt folgende Klassen an Daten:

 

Datenlinks

Für die Verknüpfungen, die sich aus den Datenfluß ergeben lassen sich folgende Klassen definieren:

 

Input-Links

Interne Links

UI-Output-Link

 

Die Informationen, die der Link enthält, müssen ausreichen, um eine Abfrage über der Menge der Rohdaten in der "statischen" Struktur erzeugen bzw. ergänzen zu können. Mit solchen Abfragen werden Protokolle zusammengesetzt, in Folge mit Daten gefüllt und die Ergebnisse als Output repräsentiert.

 

Asbru-Protokolle

Die Asbru-Protokolle selber sind von [Miksch97a] in BNF-Form spezifiziert, werden aber im Zuge des Asgaard-Projekts objektorientiert implementiert. Die Verschachtelung von Protokollen erfolgt über Links, also über eine spezielle Relation. Damit ein Asbru-Protokoll ausgeführt werden kann, müssen folgende Informationen vorhanden sein:

 

Wichtig ist nicht nur, die Informationen für die Ausführung mit einem Exekutor zusammenzutragen, sondern auch geeignete Pläne auszuwählen. Dazu müssen geeignete Attribute für Suchabfragen zur Verfügung gestellt werden, aufgrund derer entscheidbar ist, welche Pläne für eine weitere Evaluation in Frage kommen. Diese Attribute sind noch nicht spezifiziert und von den implementierten Algorithmen abhängig. Es muß also möglich sein, zur Laufzeit zusätzliche Attributlisten in das Datenmodell "einzuhängen".

 

Dokumentseite (Pages)

Stellt mehrere inhaltlich zusammengehörigen Objekte in einem realen Kontext zusammen (siehe S. *) und bildet eine zum Verständnis der dargestellten Daten minimale "Grundeinheit" dar.

 

Dokumente

Enthalten eine nach unterschiedlichen Kriterien ausgewählte Datenmenge, bestehend aus Dokumentseiten. Solche Dokumente (z.B. die Krankengeschichte eines Patienten, das Tagebuch eines Sportlers, eine Darstellung verschiedener typischer Ausprägung einer Krankheit aufgrund realer Fälle, usw.) sollen auch für die Manipulation von Datenmengen (z.B. Daten für eine Analyse zusammenstellen) durch den Benutzer herangezogen werden können.

 

Outputdaten

Werden nicht in der Datenbank gespeichert, es sei denn, sie wurden von einem Asbru-Outputlink als Inputdaten zurückgespiegelt.

Zurück zum Inhalt

 

4.2.4 Datenklassen

Asgaard will dem objektorientierten Ansatz folgen. Im Folgenden sollen die wesentlichen Klassen von Daten dargestellt werden, die bei der Implementierung in Form von "Datenobjekten" (siehe Kapitel 4.3.2 S.*) umgesetzt werden. Die vorgestellten Datenklassen orientieren sich nicht am internen Aufbau, sondern sind jene die dem Benutzer des Systems zur Verfügung gestellt werden. Allen Datenklassen gemeinsam ist, daß sie sich gegenseitig (mit "Links") referenzieren können.

 

Begriffe

Dienen als Knoten um Taxonomien aufbauen zu können und so Textfelder bei Inputdaten durch Auswahlfelder und somit numerische Daten (durch Referenzen auf "Begriffe") ersetzen zu können. Andere Datenobjekte können somit beliebig (und auf mehrere unterschiedliche Weise) strukturiert werden, was auch zur Navigation bzw. bei der Darstellung der Datenmenge notwendig ist.

 

Personen

Sind die agierenden Menschen: Ärzte, Patienten, Trainer, usw. (siehe Kapitel 1.2.2 S.*), sie können mit dem System arbeiten und Zugriffsrechte zu Datenbereichen definieren. Personen können zu Gruppen zusammengefaßt werden.

 

Unterklassen:

 

Inputdaten

Um kontinuierliche Daten (siehe Kapitel 4.2.1 S.*) erfassen zu können, werden diese zu einem Datenobjekt zusammengefaßt und als solche mit anderen Datenobjekten (auch von anderer Klasse) verbunden. Damit muß zur Laufzeit eine Tabelle erstellt und in das Datemodell eingefügt werden können, die diese Daten aufnehmen kann. Eine Klasse von Inputdaten muß auch jene Methoden implementieren, mit denen diese Daten eingegeben und dargestellt werden können (also zumindest eine Importschnittstelle).

 

Unterklassen:

 

Plan

Asbru-Pläne (bzw. Protokolle) sind "atomar", d.h. Subpläne werden nicht integriert sondern referenziert. Inputdaten werden ebenfalls nicht in diesem Datenobjekt gespeichert (außer sie kommen nur dort vor, wie z.B. Defaults) sondern z.B. über einen Verweis auf ein Inputdatenobjekt. Um nach geeigneten Plänen suchen zu können, müssen (wie bei Inputdaten auch) charakteristische Attribute in einer externen Tabellen an das Datenmodell "dazugelinkt" werden. Ein Asbru-Plan muß Methoden zur Verfügung stellen, welche die Schnittstelle zu den spezifizierten Tasks bilden (siehe Kapitel 3.3 S.*).

 

Unterklassen:

 

Dokumente

Sind Sammlungen von Datenmengen (z.B. eine Krankengeschichte), die aufgrund von Filterkriterien (z.B. das Datum) zusammengefaßt und dargestellt werden können – siehe voriges Kapitel.

 

Abfragen

Bilden die "Output-Schnittstelle" um nach geeigneten Datenobjekten suchen zu können und Daten zu extrahieren. Diese Schnittstelle bildet das Interface für Datenexporte und kann auch intern verwendet zu werden um "dynamische Links" zu bilden, d.h. die Verknüpfung zu Daten wird erst bei Bedarf ausgeführt, etwa um einen Plan mit den aktuellen Daten "zu füllen".

Zurück zum Inhalt

 

4.2.5 EER – ein Lösungsansatz

Im Vorprojekt "CTS" haben wir die Struktur noch in Form eines klassischen ERs "ausgebreitet", was zu einer Unmenge an Entitäten geführt hat. Diese Struktur ist nur schwer wartbar und widerspricht somit dem formulierten Designziel im Echtbetrieb ohne Datenbankadministrator auszukommen. In Folge wird eine Weiterentwicklung dieses in [Hammer97d] spezifizierten Modelles dargestellt, das die Problematik und einen Lösungsansatz illustrieren soll.

 

Klassenregistrierung

Dazu muß das Modell in seiner bisherigen Form um eine "Klassenregistrierung" erweitert werden, in der die logische Zuordnung einzelner Tabellen zu ihrer Funktion im Sinne des bisher vorgestellten Modells erfolgt. Optional (Prior. C) kann hier auch eine OOKlassenvererbung von Datenstrukturen vorgenommen werden, die dann auch Datenkonversionsvorschriften für den Match von "alten" und "neuen" Daten enthält.

 

Personalien und Beziehungen

Bei den "statischen" Personalien wollen wir uns auf das Notwendigste beschränken und nur Daten aufnehmen, die sich nicht (mit Ausnahme der Namensänderung bei Heirat) ändern, und der Beziehungsstruktur von Personen zueinander, die die Grundlage für die Zugriffsrechte bilden. Weitere administrative Daten wie Wohn- und Arbeitsadressen sind nur mit Priorität C vorgesehen, da die Anforderung daran nicht unabhängig vom Einsatzgebiet des Gesamtsystems ist.

Der Schlüssel für eine Person wird vom System selber gebildet, die Duplikatsüberprüfung erfolgt über die Sozialversicherungsnummer. Sollte eine Person unabhängig voneinander mehrmals erfaßt worden sein, so muß die Konsistenz des Schlüssels bei Datenreplikation wieder hergestellt werden könne (Prior. B).

 

Designprinzipien

Die Prinzipien, die zu diesem sehr konzentrierten EER geführt haben sind:

 

Abbildung 24 EER Lösungsansatz

Beschreibung

Person

Umfassen alle "Subjekte", die Daten in das System einfließen lassen. In unserem Sinne sind das meistens physische Personen, Es können aber auch Geräte sein, die automatisch Daten über eine Person liefern. Andererseits kann jemand Überlegungen zu einem "typischen Fall", also einen Menschen der nicht wirklich existiert, einem "virtuellen Menschen" anstellen.

Gruppe

Um Personen zu gruppieren (mit der Relation "gehört zu"), wiederzufinden, auszuwählen und vor allem um die Zugriffsrechte zu regeln.

Registry

Alle Datenobjekte, mit denen der Benutzer hantiert sind "registriert" und setzen sich aus den "verborgenen" Systemteilen und anderen registrierten Datenobjekten hierarchisch zusammen. Dabei wird die statische Struktur des Systems verwaltet und die Daten für automatische Aktionen bereitgestellt. Dabei wird auch die Verbindung zu den UI-Komponenten (also die Schnittstelle nach außen) registriert.

Fälle

Beinhaltet die Registry die statische Struktur von Datenobjekte, so fixiert die "Fallbibliothek" einen (temporären) Zustand der Datenbank bezüglich einer Person. Dadurch soll die "Geschichte" erhalten werden können.

Link

Die "Detailsverwaltung" einzelner Datenspalten werden von den "Links" übernommen. Sie haben die gleiche Aufgabe wie die "Registry", beinhalten aber jeweils die Verbindung eines Datums zwischen zwei Systemteilen (die nicht alle in der Datenbank liegen müssen: In diesem Fall werden Daten an die oder von der Datenbankschnittstelle geliefert).

Dokumente

Sind Datensammlungen, mit denen sowohl der Benutzer operiert, als auch jede Art von Abfrage innerhalb des Systems mit solch einem Dokument verknüpft ist. Das kleinstmögliche Dokument (außer dem leeren Dokument) beinhaltet (besser: selektiert aufgrund der durch das Dokument gesetzten Selektionskriterien) die Daten einer Seite. Die Relation "besteht aus" wird dabei nicht direkt implementiert, sondern über die Angabe der verwendeten Selektionskriterien.

Page

Eine Seite enthält die kleinste Menge an zusammengehörigen Daten. Änderungen beziehen sich nicht auf den Datensatz einer Tabelle, sondern auf eine Seite. Eine Seite kann viele unterschiedliche Tabellen (und auch UI-Komponenten) enthalten oder ganz wenige.

T_*

Das Format der Inputdaten wird vom Benutzer in der "Designphase" festgelegt und hängt von der zugrundeliegenden medizinischen oder sportlichen Konzeption ab. Im Laufe der Zeit können sich also viele Tabellen ansammeln, die in das System (verteilt) eingelinkt werden können. Dabei hat eine Inputtabelle drei wesentliche Dimensionen:

 

  • Die Unterscheidung von Soll- und Istdaten.

 

  • Die Unterscheidung der "Verarbeitungsstufe" (von Roh- zu Outputdaten).

 

  • Die vom Benutzer festgelegte Datenstruktur.

 

Grundsätzlich muß das Ziel beim Design solch einer Tabelle sein, wesentliche Informationen nicht in der (statischen) Struktur, sondern in Form von Daten abzulegen.

Protokoll

Enthält ein "atomares" Asbru-Protokoll (ohne Subteile), das über die Registry verschachtelt und zusammengesetzt wird. Dynamische Datenfluß erfolgt, einmal statisch installiert, ohne weiteres Zutun des Benutzers über die "Links". Dabei unterscheiden sich "skeletale Pläne", die keine "Echtdaten" enthalten und tatsächlich angewandte Fälle (mit den verwendeten Daten).

Component

sind für die Selektion von Protokollen wichtige Protokollteile.

Zurück zum Inhalt

 

4.3 Implementation

Das Asgaard-Projekt soll komplett objektorientiert mit Java implementiert werden und setzt auf einer relationalen Datenbank (einem SQL-Server gemäß ANSI-SQL) auf. Das API des Datenbanklayers ist im Anhang (siehe Kapitel 6.2 S.*) detailliert spezifiziert. Die in Abbildung 25 dargestellte Schnittstelle ist im Package "Asgaard.Skid" enthalten.

 

Abbildung 25 Objekmodell

 

Die Schnittstelle ist in Form eines Objektbrokers in "Asgaard.Skid.DataObjectCollection" realisiert, der zentral die Funktionalität des Servers für einen Client zur Verfügung stellt.

 

Alle Objekte, die in der Datenbank repräsentiert werden sollen, müssen Nachfolger der Klasse "Asgaard.Skid.DataObject" sein, das die notwendigen Methoden enthält um in der Datenbank verwaltet werden zu können. Die Datenbankaktivitäten werden über "Stored Procedures" serverseitig abgewickelt.

 

Ein Test- und Democlient steht in der Klasse "Skid" zur Verfügung, zur Installation siehe Kapitel 6.3 (S.*).

 

Diese Implementierung ermöglicht sowohl einen konzentrierten Clients (2-Schicht Architektur), als auch die in Kapitel 2.2.2 (S.*) angeführte 3 Ebenen Architektur mit dem "Objectbroker" als Middleware.

Zurück zum Inhalt

 

4.3.1 EER - Implementiertes Modell

Das ER-Modell hat viel von seiner Komplexität verloren, da die meiste Funktionalität in den Objekten realisiert ist. In Folge soll deshalb das Augenmerk auf der Schnittstelle zwischen "Objektbroker" und Datenbank liegen, also wie die spezifizierten Datenklassen am SQL-Server abgebildet sind.

 

Abbildung 26 implementiertes EER

 

Wie man in Abbildung 26 sieht, sind nur "wenige" Tabellen fix festgelegt. Alle Datenobjekte werden in der Registry als "Large Binary" gespeichert und lediglich die Schlüssel bleiben im Entity. Die Masse an Daten wird in die T*L* Tabellen ausgelagert, die zur Laufzeit erstellt und in das System "gelinkt" werden können. Solch eine T*L* Tabelle wird von einem Datenobjekt verwaltet, das in der Registry gespeichert ist.

 

Datenobjekte haben zwei Vererbungsstrukturen: Eine "Class-Struktur", d.h. sie werden mit einer bestimmten Objektklasse verbunden (Diese sind in der Datenbank als eigene Datenobjekte repräsentiert und außerhalb als von "Asbru.Skid.DataObject" abgeleitete Klasse) und eine "Clone-Struktur", mit der Datenobjekte z.B. in unterschiedlichen Bearbeitungsschritte instanziert werden können. Autor ist die Person, die Daten oder Datenobjekte in das System einfließen lassen und Owner jene Person (oder Datenobjekt) auf die es sich beziehen.

 

Die Link-Relation beinhaltet alle möglichen Beziehungen zwischen Datenobjekten (siehe Kapitel 4.2.3 S.*). Die Pages bilden eine Klammer über die Datenobjekte einerseits und die in den T*L* enthaltenen Daten andererseits. In diesen T*L* Tabellen können sich z.B. Rohdaten (Inputdaten-Objekte), oder Components (Asbru-Pläne) befinden.

 

Durch diese Konstruktion ist einerseits die strukturelle Skalierbarkeit gewährleistet und trotzdem kann die Performance eines SQL-Servers bei minimalen administrativen Aufwand genutzt werden.

 

Schlüssel

Alle im folgenden angeführten Datentypen sind Standard SQL-Typen mit Ausname von "primKey", welche ein benutzerdefinierter Datentyp "NUMBER (14,0)" ist, was einer 6-Byte Integer entspricht.

 

RNr

2 HiByte

4 LoByte

Abbildung 27 Primärschlüssel "Registry" und "Page"

 

RNr: Registry Object Number (Abbildung 27)

 

Der Schlüsselraum wir von den Tabellen "Registry" und "Page" gemeinsam genutzt, neue Schlüssel werden von der Stored Procedure "GetRegistryKey" geliefert.

 

Registry

Beinhaltet die verschiedenen Datenobjetkte. 

Name

Datentyp

Beschreibung

RNr

PrimKey

Primärschlüssel des Datenobjekts (Schlüsselraum m. PNr)

RClass

PrimKey

Schlüssel auf das Klassen-Datenobjekt

RClone

PrimKey

Clonvorlage des Datenobjekts

RAutor

PrimKey

Autor des Datenobjekts

ROwner

PrimKey

Bezug des Datenobjekts

TScreated

TSmodified

TSlink

TSclosed

Timestamp

Timestamp

Timestamp

Timestamp

Wann das Datenobjekt erzeugt wurde (autom.)

Wann das Datenobjekt zuletzt geändert wurde (autom.)

Zeitbezug (Person: Geburt, Plan: Therapiebeginn), optional

Zeitbezug (Person: Gestorben, Plan: Therapieende), optional

RState

SmallInt

Bit-codierT

root

system

userDefined

deleted

Erste Ebene der Objekthierarchie

Systemobjekte (normalerweise verborgen)

Verteilt erweitert

Gelöschtes Datenobjekt

private

protected

public

Nur ich darf auf meine Daten zugreifen

Die in GehörtZu definierten Rechte gelten

Alle dürfen meine Daten lesen

RName

VarString

Name des Datenobjekts

RObject

IMAGE

Large Binary mit dem Datenobjekt

 

Link

Name

Datentyp

Beschreibung

RNrFrom

PrimKey

PrimKey Teil 1: Von Datenobjekt

LOrder

SMALLINT

PrimKey Teil 2: Lokale Ordnung innerhalb der Zuordnung

RNrTo

PrimKey

PrimKey Teil 3: Zu Datenobjekt

LPosition

PRIMKEY

Rolle der Beziehung (Sportler, Patient, Trainer, Arzt, ...)

LState

SMALLINT

Bit-codierT

order

access

* read

* add

* modify

* execute

partOf

Taxonometrie

Zugriffsrechte

In Daten (von "RNrFrom") Einsicht nehmen

Daten (bei "RNrFrom") ergänzen

Daten (bei "RNrFrom") editieren

Datenobjekte von " RNrFrom" verwenden

Zusammensetzen von Objekten

TScreated

TSmodified

Timestamp

Timestamp

Wann das Datenobjekt erzeugt wurde (autom.)

Wann das Datenobjekt zuletzt geändert wurde (autom.)

TSbezug

Timestamp

Wann diese Beziehung begonnen hat

TSclosed

Timestamp

Wann sie endet: (Zugehörigkeitsgeschichte)

In dieser Relation werden insbesondere die Zugriffsrechte und alle Ordnungsrelationen verwaltet.

 

Page

Name

Datentyp

Beschreibung

PNr

PrimKey

PrimKey Teil 1: Seitennummer (Schlüsselraum gem. m. RNr)

POrder

SMALLINT

PrimKey Teil 2: Lokale Ordnung innerhalb der Zuordnung

RNrOwner

PrimKey

Besitzer der Seite

LState

SMALLINT

Bit-codierT

order

access

* read

* add

* modify

* execute

partOf

Taxonometrie

Zugriffsrechte

In Daten (von "RNrFrom") Einsicht nehmen

Daten (bei "RNrFrom") ergänzen

Daten (bei "RNrFrom") editieren

Datenobjekte von " RNrFrom" verwenden

Zusammensetzen von Objekten

TScreated

TSmodified

Timestamp

Timestamp

Wann das Datenobjekt erzeugt wurde (autom.)

Wann das Datenobjekt zuletzt geändert wurde (autom.)

TSbezug

Timestamp

Wann diese Beziehung begonnen hat

Um den Schlüssel konsistent zu halten, müssen bei Replikation alle Einträge, die auf ein geändertes Datenobjekt verweisen ausgetauscht werden.

 

T*L* (Inputdaten und Protokolle)

Tabellenname: T* = "T" & Hi(RNr) & "L" & Lo(RNr) des Eintrages der Table in die Registry 

Name

Datentyp

Beschreibung

PNr

PRIMKEY

PrimKey Part 1: PrimKey der Page bzw. des Datenobjekts

POrder

SMALLINT

PrimKey Part 2: pro Table Local Running Number

*

*

frei definierbar

 

Temporal

Wird temporär angelegt, um aufgrund des angemeldeten Benutzers die Liste mit den Datenobjekten zu erstellen, auf die er zugreifen darf. Dadurch wird die Zugriffsgeschwindigkeit drastisch erhöht. Grundlage dieser Tabelle ist die "Registry". Diese Tabelle wird pro Client lokal bei jedem Login angelegt. Änderungen der Registry im Server müssen den Clients mitgeteilt werden.

Zurück zum Inhalt

 

4.3.2 OOD-Datenobjekte

Im Folgenden werden typische Beziehungen zwischen instanzierten Datenobjekten dargestellt (Es können prinzipiell alle eingehen – wenn sie implementiert werden). Der Übersicht wegen wurde die komplette OOD-Notation nach [Pomb93] vereinfacht. Klassen sind dünn umrahmt und instanzierte Objekte dick. Für "Part-Of" Beziehungen wird die EER-Notation verwendet, da diese auch so im Datenmodell nachvollzogen werden.

 

Begriffe (IndexText)

Alle Textwerte, die im System vorkommen, werden über einen Indexwert repräsentiert (Abbildung 28). Das können sein:

 

Abbildung 28 OOD Datenobjekt "Begriff"

 

Connection

"ordnet" beinhaltet eine lokale Ordnung von Begriffen, wobei Begriffe auch mehrfach und anderen Datenobjekten zugeordnet werden können.

 

"Autor" legt die Zugriffsrechte (ändern) fest.

Methoden

Indextexte verwalten und ordnen und zuordnen

 

"Systembegriffe" sind nicht editierbar und können ausgeblendet werden

 

"Rootbegriffe" verweisen in der Relation "ordnet" auf die erste Ebene. Die Begriffe können von dort aus in einer baumartigen Struktur angeordnet werden und mehrfach vorkommen (es sind also nur Links).

 

Personen und Gruppen

Gruppen und Personen werden unisono behandelt. Der wichtigste Unterschied ist, daß Gruppen nicht physisch existieren können und nur einen Namen haben (und keinen Vornamen) (Abbildung 29):

 

Abbildung 29 OOD Datenobjekt "Personen" bzw. "Gruppen"

 

Connection

"Zugriff" die Verwaltung der Zugriffsrechte auf Datenobjekte, die einer anderen Person gewährt werden. "Autor" legt fest, wer die Personalien erfaßt hat, "Owner" ist die Person selbst.

Methoden

Verwaltung der Personalien einer Person, Wiederfinden von Personen und Zuordnung zu Gruppen. Die unterschiedlichen Klassen (Person, Gruppe, ...) können durch unterschiedliche Icons dargestellt werden.

Attribute

TSlink

Geburtsdatum

 

TSclosed

Sterbedatum

 

RName

Namenskürzel / Kurzbezeichnung (autom. Vorschlag)

 

RObject

(Nach)Name, Vorname, Titel, Anrede, verschlüsseltes Paßwort, Profil (Desktopeinstelungen des UI), Bemerkungen, ...

 

Inputdaten

Enthält Daten in verschiedenen Verarbeitungsphasen und implementiert Schnittstellen zur Umwelt. Die Daten können auch in eine "eigene" Tabelle ausgelagert werden. (Abbildung 30).

 

Abbildung 30 OOD Datenobjekt "Inputdaten"

Connection

"Autor" der die Datenstruktur angelegt hat, "Owner" auf wen sie sich beziehen. "bind" und "contain" bilden die Klammer zwischen verwendeten Daten in anderen Datenobjekten, die mit "link" an diese Inputdaten gebunden sind. Dadurch werden "mehrschichtige" Dateninstanzen (z.B. für Soll/Istdaten und die verschiedenen Bearbeitungsschritte) möglich.

Methoden

Legt die Datenstruktur einer definierbaren Table fest und registriert sie. Dabei werden die einzelnen Felder beschrieben. (Standardwerte, Ranges, Formate, Indextextwerte, ...) Außerdem kann eine Schnittstelle "nach außen" (zur Datenerfassung) implementiert werden.

Definition

Der Tablename wird durch den Primärschlüssel des Datenobjekts definiert.

 

Abfrage

Dienen Inputdaten-Objekte vornehmlich der Aquirierung von Daten, sollen "Abfrage" durch Selektionskriterien definierte Datenobjekte mit den dazugehörigen Verknüpfungen liefern (Abbildung 31).

 

Abbildung 31 OOD Datenobjekt "Abfrage"

 

Connection

"Autor" der die Abfrage angelegt hat "select" wählt entweder (1) einen Dokument(bereich) oder (2) eine Sammlung von anderen Datenobjekten aus und verbindet diese mit den über Page referenzierten Daten.

Klassen

"statisch", "dynamisch"

 

Der Unterschied zwischen "statisch" und "dynamisch" liegt darin, daß für "statische" Abfragen das Result-Set der Abfrage gespeichert wird und der Zustand quasi "eingefroren" wird. Das ist dann notwendig, wenn das Ergebnis reproduzierbar sein soll. (Prior C)

Methoden

Eine Abfrage beinhaltet eine Schnittstelle, mit der Selektionskriterien für Datenobjkete angegeben werden können und eine weitere, welche die gefundenen Objekte beinhaltet. Teil dieses Ergebnissets sind die Schlüssel der von den gefundenen Datenobjekten referenzierten weitere Objekten. Auf diese Weise kann man (wenn keine Selektionskriterien angegeben sind) bei einem Objekt angefangen "Schritt für Schritt" die ganze Datenbank "herausziehen", da die Objekte untereinander ja vernetzt sind.

 

Asbru-Plan (Asbru-Protokoll)

Wie eingangs erwähnt, werden Plan und Protokoll synonym verwendet und soll lediglich im Sprachgebrauch zwischen Soll- (Plan) und Istrepräsentation (Protokoll) von Asbru unterscheiden – für das Datenobjekt "Plan" macht das keinen strukturellen Unterschied. Wie auch die Inputdaten-Objekte können Plan-Objekte eine Tabelle mit spezifischen Schlüsselattributen anlegen, um von einem Exekutor gewertet werden zu können. Sie können dabei auch die Tabellen des "Klassenobjekts" nutzen (das ihre Klasse in der Datenbank darstellt), um eine einheitliche Grundlage für diese Auswahl zu bieten. (Abbildung 32).

 

Abbildung 32 OOD Datenobjekt "Plan"

 

Connection

"Autor" der den Plan angelegt hat, "Owner" auf wen er sich bezieht, "Clone" ist die Planvorlage, die verwendet wurde. "Link" ist die direkte Verbindung zu Datenobjekten mit relevanten Daten (insbesondere zu seinen Subplänen und Input-Datenobjekten) oder erhällt über "Abfragen" der Zugang zu einer komplexen Zusammenstellung von Objekten.

Klasse

Skeletaler Plan, instanziertes Protokoll sowie die unterschiedlichen Arbeitsschritte (verifiziert, validiert, selektiert, ...) (siehe Abbildung 20 S.*).

Methoden

Organisation und Verwaltung der Pläne und seiner Subpläne. Dadurch, daß diese nur "gelinkt" werden, sind Planteile wiederverwendbar. Jedenfalls sind zwei unterschiedliche Bearbeitungsarten identifizierbar: Die Erstellung bzw. Wartung von Plänen (statisch), die Verknüpfung mit konkreten Fällen (dynamisch). Das im Kontext der bereits angesprochenen Arbeitsschritte. Der Zugang ist dabei einerseits für den Exekutor (im Hintergrund) und für den Benutzer (Visualisierung) unterschiedlich.

  

Dokumente

Ein Dokument wählt eine Datenmenge aus (Abbildung 33). Das können personenbezogene Datenmengen sein, z.B. eine Krankengeschichte oder ein Trainingstagebuch oder konstruierte Datenmengen, z.B. alle Tests eines bestimmten Personenkreises.

 

Abbildung 33 OOD Datenobjekt "Dokumente"

 

Connection

"Autor" der das Dokument angelegt hat, "Owner" auf den es sich bezieht. Es faßt eine Sammlung von "Pages" und der darin referenzierten Datenobjekte zusammen.

Klasse

Standarddokumente (werden pro Person autom. angelegt) und benutzerdefinierte Dokumente.

Methoden

Wählt eine Datenmenge aus, die über Einschränkungen (z.B. Datum) weiter eingeschränkt werden kann. Es soll in mehreren Darstellungsarten (Index, Vollansicht) den Benutzer einen Überblick über die vorhandenen Informationen und den Stand z.B. der Behandlung (Training, Projektfortschritt, ...) geben. Administrativ wichtigste Aufgabe ist die Erstellung und Verwaltung der Seiten und darin enthaltenen Links.

Zurück zum Inhalt


 

5 Conclusio

 In diesem Kapitel möchte ich die Erkenntnissen, die ich im Rahmen dieser Arbeit gewonnen habe zusammenfassen und Ausblicke auf weiterführende Möglichkeiten darstellen.

 

5.1 Reuse & Knowledge Discovering Databases

Reuse ist ein Schlagwort der Softwaretechnik. Im Fall dieser Arbeit hat sie doppelte Relevanz: Einerseits zielt das implementierte Modell auf Wiederverwendung von Daten und Wissen ab, und andererseits soll "Skid" in nächster Zukunft als Grundstein für weitere Arbeiten dienen.

 

Der zweite Punkt war leicht zu erfüllen, es gibt eine CD mit der kompletten Entwicklungsumgebung, allen notwendigen Sourcen und der dazugehörigen Dokumentation und eine kurze Installationsanleitung im Anhang (siehe Kapitel 6.3 S.*). Die Sprache Java und javadoc im speziellen entstand diese Dokumentation fast "von selbst".

 

Abbildung 34 Systemmigration

 

Um den ersten Punkt haben wir "gerungen", denn Daten und deren Strukturen ändern sich sehr viel rascher als einem Softwareentwickler lieb ist. Das Konzept der "Links" und die Fähigkeit zur strukturellen Skalierung der Datenbank ermöglicht es, neue Datenstrukturen verteilt und zur Laufzeit in das System zu integrieren – ohne einen Systemadministrator zu benötigen. Der Preis war ein im Laufe der Entwicklung "schmelzendes" Datenmodell, das zum Schluß fast schon von objektorientierten Konzepten überholt schien. Die weite Verbreitung von SQL-Datenbanken wird wahrscheinlich dazu führen, daß unter einem gemeinsamen Datenbank-API die relationale und die objektorientierten Datenbankmodelle integriert werden (Abbildung 34).

Abbildung 35 Information Reuse

 

Das Thema "Knowledge Discovering Databases" (KDD) ist einer der Forschungsthema am Institut für Softwaretechnik. Das Konzet der "Datenlinks" ermöglicht im Prinzip die uneingeschränkte Nutzung "externer" Informationsquellen (Abbildung 35). Das Asgaard-Projekt hat einen Schwerpunkt in der Wissensrepräsentation bei Planungsproblemen und kann in dieser Domäne eine Wissenskomponente "beistellen".

 

Der Nutzen liegt auf der Hand. In praktisch allen Betrieben, insbesondere in Krankenhäusern, existieren bereits Unmengen an elektronisch gespeicherter Information. Allerdings ohne die Möglichkeit diese Daten optimal zu verwerten, da zumeist eine primäre Funktion im Vordergrund steht und für eine "vernetzte" Nutzung das entsprechende "Wissen" fehlt. In jedem Fall stellen Daten eine Ressource und eine Investition dar, die genutzt werden sollte.

Zurück zum Inhalt

 

5.2 Auswahl und Klassifikation

Entscheidend für die Funktion der Datenbank und in Folge für die Akzeptanz einer Software, die aus dem Asgaard-Projekt entstehen soll, sind die Such- und Bewertungsfunktionen für in der Datenbank gespeicherte Pläne. Derzeit sind nur rudimentäre Auswahlmethoden implementiert, da für die Bewertung von Plänen ein funktionierender Exekutor (siehe Tasks 6 und 7 Kapitel 3.3 Seite *) die Voraussetzung ist, den es aber noch nicht gibt.

 

Das objektorientierte Interface der Datenbank und skalierbare Struktur des Datenmodells ermöglicht eine einfache Erweiterung dieser essentiellen Funktionalität. Dadurch können weitere Techniken für Klassifikation und Auswahl von Plänen angewandt werden, z.B.

 

Mir erscheinen diese beiden Modelle deshalb relevant, da sie umfangreiche Beispielsammlungen voraussetzen, Strukturen impliziert darstellen können und mit wenig "Expertenwissen" zum Modellieren dieser Strukturen benötigen. Letztere Eigenschaft wäre eine gute Ergänzung zum formalen Ansatz, den Asbru verfolgt. Ein Nachteil ist die geringe Erklärungskapazität dieser Algotithmen, die gerade für die Anwendung durch Ärzte wichtig wäre.

 

Die Möglichkeiten solcher Methoden reicht über Navigation und Auswahl geeigneter bzw. gesuchter Datenobjekte hinaus zur automatischen Generierung neuen Wissens im Sinne von Knowledge Discovery in Databases (KDD) [Fayyad95] (siehe Task 1). Dafür würden sich in diesem Kontex auch z.B. "Bayesian Belief Networks" [Jensen96] anbieten, einen Modell, das neuronalen Netzen ähnelt und Wahrscheinlichkeiten durch ein Netzwerk von Fakten propagiert.

 

Die notwendigen Wahrscheinlichkeiten könnten automatisch aus dem Fundus der Planbibliothek extrahiert werden und bietet die Möglichkeit Erklärungen zu motivieren. Das Problem dabei ist die notwendige statistische Unabhängigkeit der verwendeten Attribute, die nicht immer bekannt ist. (Weil die wissenschaftlichen Hintergründe in der jeweiligen Problemdomäne noch nicht weitreichend genug aufgearbeitet sind.)

 

Das Asgaard – Projekt beschäftigt sich mit der Unterstützung von Therapieplanung, wendet dabei aber Methoden zur "Prognostik" von Entwicklungen an. Für mich ist das sehr verwandt mit der Problematik der Diagnostik. Da ja auch die tatsächlichen Verläufe der Umsetzung von Plänen in der Realität dokumentiert wird, ist die Entwicklungsrichtung zu einem System, das den ganzen medizinischen Arbeitsablauf unterstützt, nur logisch.

 

Das in dieser Arbeit implementierte Datenbankinterface ist jedenfalls dafür ausgelegt, den "Playground" für Experimente mit unterschiedlichen Methoden anzubieten. Die Auftrennung der unterschiedlichen Verarbeitungsschritte und der dabei anfallenden Daten in Verbindung mit operierenden Datenobjekten (man denke an das dreischichtige Datenmodell mit den "Links") bietet die Voraussetzung immer neue Modelle zu integrieren.

Zurück zum Inhalt

 

5.3 Verteilte Komponenten

Bei der Implementierung von "Skid" ist der sehr einfache Umgang mit verteilten Komponenten aufgefallen. Der Aufwand eine verteilte Applikation zu erstellen ist mit Java drastisch gesunken.

 

Abbildung 36 verteilte Komponenten

 

Die einzelnen Komponten müssen nicht so uniform sein, wie in Abbildung 36 dargestellt, sie können durchaus unterschiedliche Funktionalität beinhalten. Die Middleware kann man im Prinzip in Application- und Webserver splitten und im Hintergrund können unterschiedliche Server weitere Dienste anbieten. Trotzdem ist die Skalierbarkeit der Middleware der Bottleneck der jetzigen Implementierung des Datenbank-APIs.

 

Ich habe derzeit eine replizierte Variante realisiert, d.h. der Schlüsselraum wird zwischen den Clients aufgeteilt und kann somit über unterschiedliche Lokalitäten konsistent gehalten werden. Um eine wirkliche Skalierbarkeit bei den Ressourcen zu erreichen, ist diese Maßnahme nicht ausreichend.

 

Java bietet eine Reihe von Mechanismen (z.B. RMI) an, um eine Synchronisierung verteilter Systeme zu erreichen, diese Entwicklung ist aber noch in der Entwicklung. Mit dem nächsten JDK (das als Betha bereits erhältlich ist) wird eine CORBA Schnittstelle standardmäßig integriert.

 

Jedenfalls ist Konsistenz in verteilten Systemen und Datensicherheit eine technische Herausforderung für die Weiterentwicklung von "Skid".

Zurück zum Inhalt


6 Anhänge

In diesem Abschnitt werden die technischen Dokumente etwas ausführlicher dargestellt, welche die Grundlage für die Kapitel 3 und 4 bilden.

 

6.1 Hierarchiediagramm

Die Analyse der Arbeitsabläufe in Bezug auf beteiligte Rollen, Verwendete und produzierte Informationen, Auslöser und funktionale Zusammenhänge.

 

 

 

 

Zurück zum Inhalt

 

6.1.1 Hierarchien (Arbeitsvorgänge)

H1 Vorbereitung

Die grundsätzliche Vorgangsweise wird von einem Expertengremium festgelegt. Dieser Schritt ist nötig, damit alle Beteiligten die gleiche Sprache sprechen. Zentrale Aufgabe ist die Festlegung auf die zu implementierende Organisation und der zu verwendenden Methoden in der Realität, aber auch deren Abbildung im System.

H1.1 Klassen ableiten

Für konkrete Aufgabenstellungen werden Teildomänen gebildet und entsprechende Datenstrukturen festgelegt, die eine Dokumentation der zugrundeliegenden Abläufe erlaubt. Es ist der erste Spezialisierungsschritt, der dazu führen soll, daß in der Durchführung nur mehr ungewöhnliche oder auffällige Ereignisse erfaßt werden müssen. Konkret müssen innerhalb der Klassenbibliothek eigene Asbru-Klassen abgeleitet und in die Beziehungsstruktur eingefügt werden.

H1.2 Templates

Hat sich der erste Schritt mit statischen Informationsstrukturen beschäftigt, soll in diesem Arbeitsschritt das "Werzkeug" für die tägliche Arbeit konfiguriert werden. Dazu werden Beispiele instanziert, die als Kopiervorlagen dienen und ein spezialisiertes Userinterface für bestimmte Teilaufgaben besitzen. Dazu gehört auch das verwendete Vokabular festzulegen. Die Trennung von H1.1 erfolgt, da sich an den dynamischen Beispielen öfter und leichter Änderungen vornehmen lassen als an den statischen Vorgaben.

H1.3 Personalien

Dieser Schritt ermöglicht die Zuweisung der Zugriffsrechte für die einzelnen Datenbereiche und die Erfassung der statischen Personaldaten.

 

H2 Design

In der Designphase werden aufbauend auf den Strukturen von H1 folgende Tätigkeiten durchgeführt:

Die prinzipielle Vorgangsweise gleicht H3 und H4, H2 ist für diese Phasen aber Voraussetzung. In H2 werden theoretische Überlegungen (z.B. ein Therapieplan für eine normierte Person) erfaßt. Der Exekutor H5 visualisiert und simuliert die Eingabedaten (siehe Kapitel 3.3 S.* ). Die Ergebnisse der Exekution liefern bei der Erstellung das Feedback. Die generischen Pläne sind von der inhaltlichen Struktur und von der visuellen Repräsentation mit der Dokumentation der Echtdaten ident, jedoch um ein logisches Regelwerk erweitert.

 

H3 Planung

Aufgrund der tatsächlichen Gegebenheiten (realer Kontext) wird der erfolgversprechendste Plan aus H2 ausgewählt und entsprechend adaptiert (z.B. Termine anpassen). Dabei liegt der Schwerpunkt nicht mehr auf der Erfassung von Wissen und Regeln, sondern aufgrund der praktischen Erfahrung des Planers wird ein langfristiger Plan für ein Individuum (oder eine ausreichend homogene Gruppe von Personen) erstellt, der durchgeführt werden soll. Auch hier wird die Planungsarbeit administrativ und durch den Exekutor H5 durch Sofortfeedback unterstützt. Ebenso wie in den Phasen H2 und H3 stehen hierfür die gesammelten Fälle der Datenbasis zur Verfügung. 

 

H4 Durchführung

In dieser Phase sollen die bisherigen Überlegungen in der Praxis umgesetzt werden. Im Unterschied zu allen anderen Phasen erfolgt sie nicht zeitdiskret in periodischen Intervallen sondern kontinuierlich und ist durch eine laufende Rückkopplung Durchführung - Adaptierung gekennzeichnet. Auf Tendenzen, die in die falsche Richtung weisen, soll möglichst sofort reagiert werden.

H4.1 Adaptierung

Kurz vor oder während der Durchführung wird der Planteil der Vollzogen und an die Verhältnisse vor Ort angepaßt. Diese Änderungen sind teilweise intuitive Eingriffe (Gefühl) oder aufgrund der äußeren Umstände (z.B. vorhandene Geräte) nötig. Wo möglich soll auch hier der Exekutor H5 unterstützen.

H4.2 Durchführung

Die Durchführung produziert auf unterschiedliche Weise Echtdaten (manuelle Dokumentation unterschiedlicher Personen, Geräteinterfaces, andere Software) und beinhaltet die intuitive Adaptierung des Planes.

H4.3 Datenerfassung

Ziel dieses Vorganges ist es, nur die Planabweichungen möglichst effizient zu erfassen. Bei der Eingabe werden syntaktische Überprüfungen und erste Rangechecks im Hintergrund durchgeführt (Task 4). Die Rohdaten sind die Basis um die theoretischen Überlegungen der Realität gegenüberzustellen.

 

H5 Exekutor

Der Exekutor ist der zentrale Task des Systems und unterscheidet es von herkömmlichen Planungstools. Es ist besteht aus einer Reihe von Verarbeitungsschritten, die auf dem gesammelten Wissen basieren. Das Ergebnis von H5 ist einerseits ein visuell aufbereitetes Feedback für H2 bis H4 und arbeitet in Form von Protokollen den Großteil der Datenbasis auf.

H5.1 Rohdatenaufbereitung

Aufgrund der Einstellungen (Datenmenge, Filterbedingungen) und/oder aufgrund der Regelmenge werden die Daten einer ersten Vorverarbeitung unterzogen. Diese können als Sofortresponse des Inputs visualisiert werden (H5.5) und dienen als Grundlage für den nächsten Schritt.

H5.2 Datenabstraktion

Die gewonnenen Werte sollen in den Kontext eingebettet und zu qualitativen Aussagen transformiert werden. Dieser Schritt gewährleistet eine zeitkontinuierliche Bewertung des Endprodukts, der Protokolle.

H5.3 Validierung

Die Protokolle werden auf ihre inhaltliche Richtigkeit überprüft (Task 5). Fehlerhafte Eingaben werden einer Nachbearbeitung zugeführt, das Ergebnis entweder visualisiert (Darstellung der Eingabedaten) oder der Simulation zugeführt.

H5.4 Simulator

Dieser Prozeß überprüft, ob die gesteckten Ziele erreicht werden können. Die einzelnen Module sind ab Task 6 definiert. Die Simulationsergebnisse werden ebenfalls visualisiert (z.B. in Form von Tips, welches das erfolgsversprechende Programm wäre) und einer weiteren Analyse zur Generierung von Know-How zugeführt.

H5.5 Visualisierung

Eine Sammlung an unterschiedlichen Visualisierungsmethoden (Diagramme, Netzpläne, Maps, Textbausteine, Listen, ...).

 

H6 Analyse

Mit weiterführenden Methoden (KDD, Datamining) soll wieder Know-How gewonnen werden. Außerdem ist dieser Arbeitsvorgang die Grundlage für eine Weiterentwicklung der Rahmenpläne in H2.

Zurück zum Inhalt

 

6.1.2 Trigger (Auslöser)

T0 System

Automatische Auslösung durch das System.

 

T1 Experten, Trainer, Ärzte

Sind jene Personen, die ihr theoretisches und praktisches Know-How einbringen.

T1.1 Expertengremium

Soll einen inhaltlichen Konsenz innerhalb der an einer Aufgabe Beteiligten herstellen.

T1.2 Experte

Ein Spezialist für Planung / Analyse für eine Teilaufgabe.

T1.3 Arzt, Trainer

Leiten die Durchführung des Planes.

T1.4 Administration

Verantwortlich für die Wartung und Konsistenz der Daten.

 

T2 Sportler, Patient

Derjenige, der den Plan vollzieht (bzw. an dem er vollzogen wird).

 

T3 Geräte

Schnittstelle zu datenerzeugenden Geräten, anderen Programmen und sonstigen automatischen Datenquellen.

 

In- und Output (Datenfluß)

 

I0 Administration

Personalien & Co.

 

I1 Experten Know-How

Wissen, das explizit (in Form von Regeln) oder implizit (in Form von Beispielen) in das System eingebracht wird.

I1.1 strategisches Know-How

Ziele (Intentionen) müssen formuliert und in Subziele aufgebrochen werden. Dazu gehören (in diesem Fall) die Wechselwirkungen einzelner Maßnahmen.

I1.2 taktisches Know-How

Wie ausgewählte Ziele in einem konkreten Fall erreicht werden sollen.

I1.3 praktisches Know-How

Wissen aus der praktischen Realisierung einer Aufgabe.

 

O2 verarbeitetes Know-How

Der Output wird in den einzelnen Stufen zunehmend konkretisiert und immer näher an die Realität angenähert.

O2.1 statische Strukturen

Die Vorbereitung des Arbeitsumfeldes (Strukturierung der Information).

O2.2 Templates

Kopiervorlagen (Hypertextfragmente), quasi "Formulare", die mit Ein- und Ausgabekomponenten angereichert sind. (Strukturierung des Userinterfaces)

O2.3 generische Pläne

Für Normfälle werden idealisierte Komplettpläne entworfen (z.B. Mehrjahresplanung im Sport vom Anfängertraining bis in die Hochleistungsphase mit WM-Vorbereitung) und in ein Regelwerk eingefügt. Jeder Plan ist wieder in eine Unterstruktur gegliedert (siehe Definition von Asbru).

O2.4 individueller Plan

Aufgrund von Echtdaten I3.1 wird ein Plan bzw. Planteile zur Realisierung ausgewählt und angepaßt. (z.B. Termine, Dosierungen, Geräte, ...) Das Programm beinhaltet eine Reihe von Maßnahmen, mit der ein Ziel (ev. mit mehreren Subzielen) erreicht werden soll.

O2.5 adaptierter Plan

Eine konkrete Maßnahme wird an die Bedingungen vor Ort angepaßt.

O2.6 Rohdaten Protokoll

Das tatsächlich durchgeführte Programm mit gesammelten Echtdaten.

 

I3 Realität

Sind I1 theoretische Überlegungen, sind I3 Informationen aus der unmittelbaren Realität, in der das System eingesetzt werden soll.

I3.1 Planungsdaten

Beschreibt die Rahmenbedingungen unter denen ein Plan realisiert werden soll - siehe O2.4 wie z.B. Termine.

I3.2 Umwelteinflüsse

Die tatsächlichen äußeren Bedingungen vor Ort.

I3.3 Echtdaten

Daten, die der oder die durchführenden Personen produzieren. Dazu gehören die tatsächlich durchgeführten Maßnahmen und deren Protokollierung, erhobene Meßwerte (ev. automatisch gespeichert - T3), objektive und subjektive Eindrücke. Die Echtdaten können entweder unmittelbar bei der Durchführung (Belastungsreaktion - z.B. Laktatentwicklung bei einem Ausdauertraining) oder auch später (Regeneration - z.B. CK-Wert nach einem Krafttraining) oder allgemeine Grunddaten (z.B. Ruhepuls) sein.

 

O4 Warnungen, Fehler

Protokolle (Pläne, Programme, Echtdaten) können bei der automatischen Exekution einer Nachbearbeitung zugeführt werden, wenn sie innerhalb des Regelwerks als nicht konsistent erscheinen. (Es sei dahingestellt, ob das Protokoll oder die Regeln angepaßt werden müssen.)

 

O5 Visualisierung

Die eingegebenen Daten werden in unterschiedlichen Bearbeitungsphasen (visuelle Repräsentation der Eingabedaten, statistische Aufbereitung, Exekution, ...) den Beteiligten wieder angeboten.

Dabei müssen einerseits unterschiedliche Formen (Textgenerator, Charts, Maps, Formeln, ...) und unterschiedliche Ausgabemedien (Bildschirm, Drucker, File) berücksichtigt werden können.

 

O6 Protokoll

Siehe Asbru. Die gewonnen Daten werden in Form von Protokollen repräsentiert. Sie sind die Arbeitsgrundlage des Systems und Input in fast allen Arbeitsschritten.

O6.1 Protokoll

Wenn Daten normiert und in die Pläne eingefügt werden, entstehen lauffähige Protokolle.

O6.2 gefiltertes Protokoll

Diese Protokolle werden validiert. Dabei wird festgestellt, ob das Protokoll im Sinne des Kontexts gültig ist und die angestrebten Ziele erreichbar sind.

 

O7 Simulationsergebnisse

Das Ergebnis der Exekution wird einerseits visualisiert und kann andererseits zur Know-How Generierung herangezogen werden. Dieses zusätzliche Feedback ist der Hauptunterschied zu konventionellen Systemen.

 

O8 Know-How

Es soll nicht nur Know-How transportiert werden (was z.B. mit generischen Plänen O2.3 passiert) sondern auch aus der Interaktion mit dem System gewonnen werden, das wieder in das System zurückfließt.

 

O5, O7 und O8

Fließen über die Benutzer in das System zurück.

Zurück zum Inhalt

 

6.1.3 Ressourcen (Betriebsmittel)

R1 Klassenbibliothek

Um in einer verteilten Datenbank die Änderungen nachvollziehen zu können, bzw. daß unterschiedlich entwickelte Protokolle Daten austauschen können, muß das Datenmodell objektorientiert erweitert werden. (Grundlage nach derzeitigen Stand aber weiterhin SQL-Technologie). Auswertungen unterschiedlicher Protokolle können dann auf Basis des gemeinsamen Vorgängers durchgeführt werden, womit alte Daten nicht wertlos werden.

R1.1 Protokolle

Sie sind die Datenträger.

R1.2 Templates

Sind vorkonfigurierte Teile des Userinterface und können Protokolle beinhalten.

 

R2 Knowledge-Database

Beinhaltet eine Abbildung der Beziehungen zwischen den einzelnen Protokollen und Methoden des Systems.

 

R3 Instanzenbibliothek

Beinhaltet R1 die statische Struktur, so sind hier die eigentlichen Daten abgelegt.

 

R4 Personaldatei

Statische Personendaten und Zugriffsrechte.

Zurück zum Inhalt

 

6.1.4 Beziehungen

 

B1 Beziehungsstruktur

Einbettung der Protokolle in ein Regelwerk, bzw. die Repräsentation der dynamischen Beziehung verschiedener Protokolle untereinander.

 

B2 Instanzierung

Verbindung eines Protokolls zu seiner statischen Struktur im objektorientierten Sinn.

 

B3 Eigentümer

Zugriffsrechte einzelner Personen zu einer Klasse von Daten (z.B. ein Patient zu seiner Krankengeschichte).

Zurück zum Inhalt

 

6.2 Datenbank API "Skid"

Die folgende API – Dokumentation wurde aus dem Source-Code mit javadoc erstellt. Für weitere Details siehe die komplette HTML-Dokumentation auf CD, die Teil dieser Diplomarbeit ist. (siehe nächstes Kapitel), das Rootfile ist "TREE.HTML".

Zurück zum Inhalt

 

6.3 Installation

Im Kapitel 3.1 wurde die praktisch Verwendbarkeit als Ziel des Projekts dargestellt, deshalb sind hier kurz die Informationen zusammengefaßt, die notwendig sind um eine funktionierende Entwicklungsumgebung aufsetzen zu können. Die Entwicklungsumgebung ist in Form von Trial-Versionen (es gelten die jeweiligen Lizenzbestimmungen, die bei der Installation angezeigt werden) für Windows95™ bzw. Windows NT 4.0™ gemeinsam mit allen Sourcen auf der beiliegenden CD (liegt auch im Institut für Softwaretechnik der TU Wien auf) enthalten. "Skid" selber ist auf allen Plattformen verwendbar, auf der es eine Implementierung der "Java-Virtual Machine" gibt.

 

Dieser Abschnitt ist als File "README.HTML" im Root der CD mit Hyperlinks zu der entsprechenden Software zu finden. Deshalb sind im Folgenden keine Pfade angegeben.

Zurück zum Inhalt


Danksagung

An dieser Stelle möchte ich mich bei all jenen bedanken, die mich in den letzten Jahren unterstützt und gefördert haben. Nicht, weil das so üblich ist, an dieser Stelle so etwas anzubringen. Eigentlich schreibe ich es für mich, um die Gefühle, die ich empfinde zu dokumentieren und mich in Jahren, wenn mir dieses Buch zufällig in die Hände fällt, daran zu erinnern.

 

Allen voran meine Liebe und mein Herz für meine Eltern und meine Schwester. Für mich sind sie von menschlicher Größe, als Vorbild in ihrem Tun, Denken und Fühlen verdanke ich ihnen mehr als nur dieses Leben.

 

Meinen Mentoren der letzten Jahre Johannes Gloggnitzer, Manfred Zeilinger und als "alten Gefährten", Trainer und Freund Peter Dworzak, die mir ein Beispiel sind und mir ihre Geduld und ihr Vertrauen erwiesen haben.

 

Meinen Freunden und Kameraden (die, die ich meine wissen es), mit denen ich lange Zeit in einem Boot gesessen bin und einer kleinen Leichtathletin (die weiß es vielleicht nicht) die einfach zur rechten Zeit am rechten Platz war.

 

Ermöglicht hat diese Arbeit meine Betreuerin Silvia Miksch – ich kann nur jeden Studenten eine derart attraktive Betreuung wünschen. Ich hoffe, daß unser Weg mit dem Projekt Asgaard noch eine Zeitlang ein gemeinsamer ist.

 

Bedanken will ich mich bei all jenen, die meine Projekte mitgetragen, unterstützt oder wohlwollend kritisiert haben. Ich glaube, es ist nicht so entscheidend, was der eine oder andere getan oder nicht getan hat. Danke, daß ihr für mich da wart.

Zurück zum Inhalt


Literatur

[Aha91]

David Aha, Dennis Kibler, MMarc Albert: "Instance-Based Learning Algorithmus" in "Machine Learning", 6, 37-66 Kluwer Academic Publishers 1991.

[Asgaard]

Die Asgaard Homepage http://www.ifs.tuwien.ac/asgaard.

[Blachon89]

Blachon "Viel Spaß beim Sport", Eichborn Verlag, 1989.

[Coulouris94]

Georg Coulouris, Jean Dollimore, Tim Kindberg "Distributed Systems" Addison-Wesley 1994

[Deitel97]

Paul und Abbey Deitel, "Java How to programm" Prentice Hall, 1997 http://www.deitel.com.

[Dicken97]

Hans Dicken, "JDBC" Thomson Publishing, 1997.

[Fayyad95]

U. Fayyad, G. Piatetsky-Shapiro, and P.Smyth "From Knowledge Discovery to Data Mining: An Overview", in "Advances in Knowledge Discovery and Data Mining", AAAI/MIP Press, 1995.

[Gosling96]

James Gosling, Bill Joy, and Guy Steele "The Java Language Specification", Sun Microsystems, 1996 specification abailable as HTML http://java.sun.com:81/docs/books/jls/html/index.html.

[Giarratano94]

Giarratano J., Riley G.: "Expert Systems - Principles and Programming", PWS, Boston, Second Edition, 1994.

[Haber84]

Paul Haber, Heinz Ruth "Österreichischer Ruderlehrplan", Österr. Ruderverband, 1984.

[Hammer97a]

Klaus Hammermüller, "Projektplan Computerunterstütztes Trainingssystem 2.0", Heeres Sport- und Nahkampfschule LStGr KA, Stand Okt. 1997 http://www.ifs.tuwien.ac.at/~hammer.

[Hammer97b]

Klaus Hammermüller, "Projektagebuch CTS", unveröffenl., Heeres Sport- und Nahkampfschule LStGr KA, Stand Okt. 1997.

[Hammer97c]

Klaus Hammermüller, "Handbuch Trainer 5.3 - Computerunterstützte Trainingskontrolle", Eigenverlag Firma G&K Hammermüller, 1997.

[Hammer97d]

Klaus Hammermüller, "Spezifikation für ein Computerunterstüttes Trainingssystem", unveröffenl., Heeres Sport- und Nahkampfschule LStGr KA, gemeinsam mit Inst. f. Softwaretechnik, TU Wien Stand Okt. 1997.

[JDBC]

JDBC-Homepage Sunsoft http://splash.javasoft.com/jdbc

 

Java FAQ http://www.www-net.com/java/faq.html

[Jensen96]

Finn Jensen "An introduction to Bayesian networks" Springer 1996

 

Aktuelle Artikel und Programme http://www.hugin.dk.

[Kohonen95]

Teuvo Kohonen "Self Organizing Maps" Springer 1995

[Jochim97]

Inke Jochim "Neurolinguistisches Training" über Alfred Korzybiski "Science and Sanity" 1933 http://www.nlp.at/theorie/ij/Kor1.htm.

[Kosara98]

Robert Kosara "AsbruBase - Spezifikation zu Asbru", unveröffentl. Spezifikation Inst. f. Softwaretechnik TU Wien 1998.

[Matthews88]

John und Caithin Matthews "Lexikon der keltischen Mythologie", Heyne Sachbuch, 1988.

[Miksch97a]

Silva Miksch, Yuval Shahar, Peter Johnson "Asbru: A Task-Specific, Intention-Based, and Time-Oriented Language for Represeting Skeletal Plans" in "7th Workshop on Knowledge Engineering: Methods & Languages" KEML-97, 1997.

[Miksch97b]

Silvia Miksch, Yuval Shahar, Werner Horn, Christian Popow, Franz Paky, Peter Johnson "Time-Oriented Skeletal Plans: Support to Design and Execution" in "4th European Conference on Planning ECP‘97" EWSP-97, 1997.

[Miksch97c]

Silvia Miksch, Werner Horn, Christan Popow, Franz Parky: "Utilizing Temporal Data Abstraction for Data Validation and Therapy Planning for Artificially Ventilated Newbord Infants" Artificial Intelligence in Medicine 8(6), pp. 543-76, 1996.

 

http://www.ai.univie.ac.at/oefai/kbs/vie-vent.html.

[Miksch97d]

Silvia Miksch, Yuval Shahar, Peter Johnson "Medizinische Leitlinien und Protokolle: das Asgaard/Asbru Projekt" in: KI-Journal 3, pp.34-36, Themenheft MEDIZIN, ScienTec Publishing GmbH, Katzenelnbogen, Deutschland, 1997.

[Oracle]

Homepage von Oracle http://www.oracle.com

[Pomb93]

Gustav Pomberger "Grundlagen des Software Engineerings", Hanser, 1993.

[Schwarz96]

Werner Schwarz "Computerunterstütztes Trainingssystem", unveröffentl. Diss. am Institut f. Sportwissenschaft, UNI Wien, Stand Nov. 1996.

[Shahar97]

Yuval Shahar, Silvia Miksch, Peter Johnson "Task-Specific Ontology for the Application and Critiquing of Time-Oriented Clinical Guidelines" in "6th Conference on Artificial Inteligence in Medicine Europe" AIME-97, 1997.

[Shahar98]

Yuval Shahar, Silvia Miksch, Peter Johnson "The Asgaard Project: A Task-Specific Ontology for the Application and Critiquing of Time-Oriented Clinical Guidelines" to appear in "Artificial Inteligence in Medicine" 1998

[Weizenbaum90]

Josef Weizenbaum "Macht der Computer und Ohnmacht der Vernunft" 8. Auflage, Surkamp 1990.

Zurück zum Inhalt


Bildnachweis

Abbildung 1 "easy way" aus [Blachon89]

Abbildung 2 Projektebenen *

Abbildung 3 Rollen im Sport *

Abbildung 4 Rollen in der Klinik *

Abbildung 5 potentielle Zielgruppen *

Abbildung 6 "Belastungsreaktion" aus [Blachon89] *

Abbildung 7 das Asgaard Modell aus [Miksch97b] *

Abbildung 8 Planhierarchie *

Abbildung 9 2-schichtige Architektur *

Abbildung 10 3-Schichtmodell nach [Dicken97] *

Abbildung 11 Alternative im methodischen Ansatz *

Abbildung 12 Wahl der Entwicklungsumgebung *

Abbildung 13 Alternative im Datenmodell *

Abbildung 14 Planung als Prozeßmodell *

Abbildung 15 Einsatz von Asbru *

Abbildung 16 Arbeitsablauf mit Asgaard *

Abbildung 17 Aufgaben in Phase 1 *

Abbildung 18 weiterführende Aufgaben aus Phase 2 *

Abbildung 19 unterstützende Tasks *

Abbildung 20 Datenfluß mit Asbru *

Abbildung 21 Anwendungszenerien *

Abbildung 22 Datenschichten *

Abbildung 23 Datenfluß in den unterschiedlichen Layern *

Abbildung 24 EER Lösungsansatz *

Abbildung 25 Objekmodell *

Abbildung 26 implementiertes EER *

Abbildung 27 Primärschlüssel "Registry" und "Page" *

Abbildung 28 OOD Datenobjekt "Begriff" *

Abbildung 29 OOD Datenobjekt "Personen" bzw. "Gruppen" *

Abbildung 30 OOD Datenobjekt "Inputdaten" *

Abbildung 31 OOD Datenobjekt "Abfrage" *

Abbildung 32 OOD Datenobjekt "Plan" *

Abbildung 33 OOD Datenobjekt "Dokumente" *

Abbildung 34 Systemmigration *

Abbildung 35 Information Reuse *

Abbildung 36 verteilte Komponenten *

Zurück zum Inhalt


Lebenslauf

 

Schulische Ausbildung

´76

4 Jahre Volksschule, Schulversuch mit mathematischem Schwerpunkt

´80

4 Jahre AHS an dem BRG X, Pichelmayergasse

´84

3 Jahre BHS an der HTBLVA Schellinggasse, H. Abt. f. Nachrichtechnik u. Elektronik

´87

3 Jahre BHS an der HTBLA Donaustadt, H. Abt. f. Nachrichtechnik u. Elektronik

´90

Matura

´90

Studienbeginn an der TU Wien mit Informatik

´93

Staatl gepr. Lehrwart, staatl. Trainerausbildung an der BAfL Wien

´98

Diplomarbeit am Inst. f. Softwaretechnik (TU Wien)

´98

GWD bei der HSNS, Sonderprojekt "Computeruntserstütztes Trainings System" (CTS) des BMLV Abt. Sport im Heer, Verlängerung des Projekts um 6 Monate

´98

2. Diplomprüfung und Sponsion zum Diplomingenieur der Informatik an der TU Wien

 

Sportlicher Werdegang

´83

Beginn mit dem Rudersport beim WRC Pirat, leistungssportliches Training bis Ende ´90

Erfolge: Österreichische Meisterschaft: 1. im Juniorenachter, 2. im Leichtgewichtszweier, mehrmalig im B-Nationalkader, Teilnahme an internat. Wettkämpfen in verschiedenen Mannschaftsbooten

´92

Trainertätigkeit (Nachwuchs) bis jetzt

´96

Jedermann – Zehnkampf

 

Praktische Arbeiten (bezahlt)

´85

1 Monat Praktikum in der Fa., Goerz Meßtechnik, Lager

´87

1 Monat Praktikum in der Fa., Goerz Meßtechnik, Plotterfertigung

´89

1 Monat Praktikum in der Fa., IBM Wien, Technischer Support

´91

Werkvertrag Umweltbundesamt, Softwarewartung

´93

Tutorium Kommerzielle Datenverarbeitung (KDV) UE am Institut für Softwaretechnik

´93

EDV für die Masters WM ´93 im Rudern in Wien (größte der Welt, 5000 Starter)

´94

Tutorium Software Engineering: (Nachfolger von KDV) durchgehend bis SS ´96

´94

Snowboardlehrer auf Schikursen bis jetzt

´95

Werkvertrag Fa. Thoerley: Marketingdatenbank mit Access 2.0 und MS SQL-Server

´96

Lehrauftrag an der BAfL Wien in der Trainerausbildung, Thema Trainingsplanung

´96

"Trainer 5.x" Entwicklung und Vermarktung von Software zu "CTS" (selbständig)

 

Projekte (nonprofit)

´90

Robotersteuerung MC8051 (Fächerübergreifendes Proj. in Kleingruppe, 5. Jahr HTL)

´90

Logbuchprogramm (öffentliches Terminal im WRC Pirat) immer noch im Einsatz

´91

Ergometerinterface MC80535 für die Österreichische Ergometermeisterschaft ´91

´91

Mitarbeit an der Zeitnehmung der Weltmeisterschaft Rudern ´91 in Wien

´92

Trainingsdokumentationssoftware (UE KDV in Gruppe zu 8, 3. Semester TU)

´92

Skriptum über objektorientiertes Software Enginering, Qualitätssicherung bei Angaben zur LVA UE

´93

Softwareengineering und Reuse von objektorientierter Software

´93

Kombination von Logbuch und Trainingsdokumentationssoftware ("Logbuch 4.0")

´94

Trainingsdokumentationssoftware unter Access 2.0

´96

Start des Projekts "CTS" - "Computerunterstütztes Trainings System"

´97

Projekt "Asgaard", einem System zur Unterstützung medizinischer Therapieplanung

 

Zurück zum Inhalt