Inhaltsverzeichnis

1  Einf uhrung  1

2  Bisherige und geforderte Funktionalit at  3

2.1  Funktionalit at des bisherigen Terminplaners  3

2.2  Anforderungen an den neuen Terminplaner  3

2.2.1  Mehrfachtermine  4

2.2.2  Geschwindigkeit  4

3  Theorie der Ablaufplanung  7

3.1  Planungsprobleme  7

3.1.1  Auftragsmodelle  8

3.1.2  Prozessormodelle  9

3.1.3  Optimierungskriterien  11

3.1.4  Beispiele  12

3.1.5  Erweiterungen  13

3.2  L osung von Planungsproblemen  13

3.3  Mehrere Prozessoren pro Operation  13

3.4  Terminplanung in der Radiologie  14

3.4.1  Das Modell f ur Serientermine  16

3.4.2  Das Modell f ur Profiltermine  16

4  Algorithmen zur Terminvergabe  19

4.1  Der Algorithmus zur Profilterminvergabe  19

4.1.1  Komplexit at  22

4.2  Der Algorithmus zur Serienterminvergabe  23

5  Implementierung  25

5.1  Schichten bei Anwendungsarchitekturen  25

5.1.1  2-Schicht-Modell  25

5.1.2  3-Schicht-Modell  26

5.2  Verwendete Softwareprodukte  27

5.2.1  Java  27

5.2.2  J2EE und EJB  28

5.2.3  Orion  30

5.2.4  Forte  30

5.2.5  SourceSafe  30

5.2.6  Oracle 8.06  30

5.2.7  JFCSuite  31

iii

iv  INHALTSVERZEICHNIS  

5.3  Benutzeroberfl ache  31

5.3.1  Steuerungsleiste  32

5.3.2  Monats ubersicht  32

5.3.3  Multifunktionsleiste  32

5.3.4  Weitere Termine / Abwesenheitsliste  33

5.3.5  Termin ubersicht  33

5.3.6  Termindialog  34

5.4  Architektur der Benutzerschicht  34

5.5  Architektur der Vorgangsbearbeitung  36

5.5.1  Session-Beans  38

5.5.2  Entity-Beans  46

5.6  Stand des Projektes  48

6  Fazit und Ausblick  49

Stichwortverzeichnis   51

Kapitel 1

Einf ¨ uhrung

Die Firma GE Medical Systems Information Technologies ¹ in Dornstadt bei Ulm ist einer der f¨ uhrenden Hersteller von Radiologie-Informationssystemen (RIS ) in Europa. Das Hauptprodukt der Firma ist das Programmpaket Medora, welches eine vollst¨ andige RIS-L¨ osung f¨ ur radiologische Kliniken und Praxen darstellt.

Ein RIS dient dazu, Radiologiepatienten und Patientenakten, Materiallager, Befundungen sowie Belegungen von Ger¨ aten, Arbeitspl¨ atzen und Mitarbeitern zu verwalten. Eng verwandt mit dem Begriff des RIS ist der des Krankenhaus-Informationssystems (KIS ). Ein KIS ist eine Software, die zentral alle Patienten des Krankenhauses erfaßt und verwaltet. uber den sogenannten HL7 -Standard ² , welcher ein Protokoll RIS und KIS kommunizieren ¨

zur elektronischen Kommunikation im Gesundheitswesen darstellt. Die Kommunikation zwi-

schen KIS und RIS verl¨ auft dabei in beiden Richtungen. Eine typische HL7-Nachricht vom KIS an das RIS w¨ are etwa die Anforderung einer CT-Aufnahme f¨ ur einen Patienten an einem bestimmten Tag. Das RIS sendet daraufhin z. B. eine Terminbest¨ atigung an das KIS zur¨ uck. HL7-Nachrichten k¨ onnen auch von anderen Krankenhausabteilungen an das RIS gesandt werden.

Das Radiologie-Informationssystem Medora wurde bisher vollst¨ andig mit der Programmierumgebung Oracle Forms entwickelt ³⁴ , welches auf die Erstellung von Datenbankanwendungen mit graphischer Oberfl¨ ache zugeschnitten ist. Forms erm¨ oglicht es auf relativ einfache

¹ http://www.gemedical.de/

² http://www.hl7.org/

³ http://otn.oracle.com/products/forms/content.html

⁴ Zum Zeitpunkt der Drucklegung wurde die Version 4.5 verwendet; es wird im Folgenden, soweit nicht anders angegeben, auf diese Version Bezug genommen

1

KAPITEL 1. EINF ¨ 2 UHRUNG

Weise, dialogbasierte Anwendungen zu erstellen, die an eine Datenbank gekoppelt sind. Ein großes Manko von Forms ist allerdings, daß der Entwickler die Oberfl¨ ache nur aus einem sehr beschr¨ ankten Satz von Komponenten zusammenbauen kann. Daher lassen die damit erzeugten Applikationen in puncto Benutzerfreundlichkeit eher zu w¨ unschen ¨ ubrig und sind

bez¨ uglich Benutzeroberfl¨ ache nicht auf dem aktuellen Stand der Technik. So ist es in einer Forms-Applikation f¨ ur den Benutzer nicht m¨ oglich, die Gr¨ oße von Fenstern oder von Unterkomponenten wie Tabellenspalten zu ver¨ andern oder Objekte zu verschieben ( Drag and

”

Drop“ ). Auch gibt es f¨ ur viele der Elemente einer modernen Benutzeroberfl¨ ache wie Kontextmen¨ us, Baumansichten usw. in Forms keine Entsprechung.

Eine weitere Problematik resultiert aus der Tatsache, daß, um in Forms eine bestimmte uber ¨ Reaktion auf ein semantisches Ereignis (Mausklick, Tastatureingabe, Nachricht ¨ Ande-

rung eines Datensatzes, usw.) zu programmieren, im Regelfall eine ganze Reihe von Behandlungsroutinen f¨ ur sog. Trigger bem¨ uht werden m¨ ussen. Die Mengen von Triggern, die f¨ ur semantische Ereignisse ben¨ otigt werden, ¨ uberschneiden sich untereinander, so daß mit stei-

gender Gr¨ oße des Projekts die Abh¨ angigkeiten zwischen Behandlungsroutinen untereinander zunehmen und es immer schwieriger wird, ¨ Anderungen am Code vorzunehmen und dabei unbeabsichtigte Seiteneffekte im Griff zu behalten.

Zu der genannten Un¨ ubersichtlichkeit steuert auch die fehlende Objektorientierung von Forms bei, die ebenfalls mit zunehmender Projektgroße immer st¨ arker ins Gewicht f¨ allt. Aus diesen Gr¨ unden beschloß man Mitte 2001, als Technologiestudie - mit Option auf Fortf¨ uhrung als Produkt - ein einzelnes Modul von Medora auf eine Plattform umzustellen, die die erw¨ ahnten M¨ angel nicht aufweisen, aber gleichzeitig eine effektive Datenbankanbindung erlauben w¨ urde. Die Plattformwahl fiel auf Java ⁵ , da es zum einen auf einfache, aber dennoch flexible Weise gestattet, graphische Benutzeroberfl¨ achen zu implementieren und zum anderen durch die J2EE -Erweiterung 3-Schicht-Architekturen unterst¨ utzt werden, somit also eine Anbindung der objektorientierten Programmiersprache an eine relationale Datenbank gegeben ist.

Als Objekt der Technologiestudie war das Terminplanungsmodul am geeignetsten, da bei ihm erstens die geringste Abh¨ angigkeit zu anderen Medora-Komponenten besteht, es also das am einfachsten austauschbare Modul ist, und zweitens bei der Terminplanung der Bedarf nach einer verbesserten Version am gr¨ oßten war. Außerdem h¨ atte bei einer Forms-Implementierung die erw¨ ahnte Zunahme der Un¨ ubersichtlichkeit und der Seiteneffekte bei den f¨ ur die neue Version geplanten Funktionen ” Serientermine“ und ” Profiltermine“ entsprechenden Mehrauf-wand bereitet.

Die vorliegende Diplomarbeit besch¨ aftigt sich mit der Konzeption und Realisierung der Technologiestudie ” Neue Terminplanung“.

⁵ http://java.sun.com/

Kapitel 2

Bisherige und geforderte

Funktionalit ¨ at

2.1 Funktionalit¨ at des bisherigen Terminplaners

Der bisherige Terminplaner verwaltet Termine auf der Basis von Terminb¨ uchern. Ein Terminbuch ist eine ¨ Ubersicht ¨ uber die Termine einer Ressource (Mitarbeiter oder Ger¨ at). Jeder Ressource ist ein Terminraster zugeordnet, welches je nach Tag verschieden sein kann. Es gibt drei Hauptdialoge, von denen mehrere gleichzeitig ge¨ offnet werden k¨ onnen:

• Tages¨ ubersicht (Stellt ein Terminbuch f¨ ur eine Ressource an einem Tag dar; siehe Abb. 2.1)

• Jahres¨ ubersicht (Stellt einen Jahreskalender f¨ ur eine Ressource dar; Mausklick auf einen Tag ¨ offnet die Tages¨ ubersicht f¨ ur diese Ressource; siehe Abb. 2.1)

• Terminauskunft (Suche nach existierenden Terminen)

Zur Anzeige einer Tages- und Jahres¨ ubersicht einer Ressource muß der Benutzer diese erst im Ressourcenauswahl-Dialog ausw¨ ahlen (siehe Abb. 2.2). Um einen neuen Termin anzulegen, klickt man in der Tages¨ ubersicht auf eine freie Rasterzeile, worauf sich ein Patientenauswahl-Dialog ¨ offnet (siehe Abb. 2.3). Nachdem der Patient, f¨ ur den der Termin reserviert werden soll, ausgew¨ ahlt ist, ¨ offnet sich der eigentliche Terminvergabe-Dialog (Siehe Abb. 2.4).

2.2 Anforderungen an den neuen Terminplaner

Unter Ber¨ ucksichtigung von Prinzipien modernen GUI-Designs sowie Kommentaren und W¨ unschen seitens von Kunden wurde ein Pflichtenheft f¨ ur die neue Version des Terminplaners erarbeitet. Es spezifiziert u. a. folgende Anforderungen:

• Die neue Terminplanung soll die gesamte Funktionalit¨ at der alten Version beherrschen

• Die Gr¨ oße jedes Fensters und abgetrennten Fensterbereichs soll ver¨ anderbar sein

• Termine sollen sowohl innerhalb eines Terminbuchs als auch zwischen Terminb¨ uchern verschoben werden k¨ onnen ( Drag and Drop“)

”

• Es sollen Mehrfachtermine unterst¨ utzt werden (siehe Abschn. 2.2.1)

3

KAPITEL 2. BISHERIGE UND GEFORDERTE FUNKTIONALIT ¨ 4 AT

Abbildung 2.1: Jahres¨ ubersicht (links oben) und Tages¨ ubersicht (rechts unten)

• Mitarbeiter und Ger¨ ate sollen in Mitarbeitergruppen bzw. Ger¨ ategruppen eingeteilt werden k¨ onnen

• Es soll eine Zwischenablage f¨ ur Termine geben

• Die Zeitdauer f¨ ur die Ausf¨ uhrung der wichtigsten Operationen soll ein bestimmtes Maß nicht ¨ uberschreiten (siehe Abschn. 2.2.2)

2.2.1 Mehrfachtermine

Mit der neuen Version des Terminplaners wurden Mehrfachtermine eingef¨ uhrt. Es werden zwei Arten von Mehrfachterminen unterst¨ utzt: Serientermine und Profiltermine. Mehr dazu findet sich in Abschnitt 3.4.

2.2.2 Geschwindigkeit

Ein vorrangiges Kriterium beim neuen Terminkalender war, daß das System f¨ ur das Eintragen eines neuen Termines und das ¨ Andern eines bereits existierenden Termines nicht l¨ anger als eine Sekunde ben¨ otigen sollte.

2.2. ANFORDERUNGEN AN DEN NEUEN TERMINPLANER 5

Aufgrund fr¨ uherer Betrachtungen [Hieber 96] wurde bisher davon ausgegangen, daß zum Erstellen von Profilterminen ein Backtracking-Algorithmus notwendig ist, der den Zeitaufwand pro einzelnem Termin stark erh¨ ohen w¨ urde. Daher wurde die Zeitspanne, die bei Profilterminen pro einzelnem Termin nicht ¨ uberschritten werden sollte, auf zehn Sekunden festgesetzt.

In Kap. 4 wird ein neuer Ansatz vorgestellt werden, der ohne den Einsatz von Backtracking- Algorithmen auskommt.

KAPITEL 2. BISHERIGE UND GEFORDERTE FUNKTIONALIT ¨ 6 AT

Kapitel 3

Theorie der Ablaufplanung

Die Ablaufplanung ist ein Untergebiet der Unternehmensforschung (auch unter der englischen Bezeichnung Operations Research bekannt). Die Anf¨ ange der Planungstheorie datieren um die Jahrhundertwende, als man begann, sich wissenschaftlich mit Problemen wie der Maschinenbelegung in Fertigungsanlagen zu befassen (Siehe [Pinedo 95]). Der wichtigste Pionier auf diesem Gebiet war Henry Gantt (1861-1919). Die ersten Resultate in Form von wissenschaftlichen Ver¨ offentlichungen wurden jedoch erst in den 50er Jahren erarbeitet. Die Ablaufplanung besch¨ aftigt sich mit der

Vergabe von Ressourcen ¨ uber einen Zeitraum hinweg mit dem Ziel, eine Anzahl

”

von Auftr¨ agen zu erledigen“ ( ¨ Ubersetzt nach [Baker 74]).

Es geht also darum, zu entscheiden, in welcher Reihenfolge eine vorhandene Anzahl Ressourcen (im terminus technicus Prozessoren genannt) eingesetzt werden soll, um eine gegebene Anzahl von Auftr¨ agen gem¨ aß einem Optimaierungskriterium zu bearbeiten. Die Auftr¨ age (engl. Jobs) setzen sich dabei aus elementaren Operationen (engl. Operations oder Tasks) zusammen, von denen jede von einem anderen Prozessor bearbeitet werden kann. Es gibt unterschiedliche Optimalit¨ atskriterien, die dabei zum Einsatz kommen k¨ onnen, oft ist beispielsweise die Minimierung der mittleren oder maximalen Bearbeitungszeit von Bedeutung, oder die Minimierung von Kosten.

Zur graphischen Darstellung einer Belegung verwendet man Gantt-Diagramme. Es gibt pro-zessororientierte (Abb. 3.1) und aufgabenorientierte (Abb. 3.2) Gantt-Diagramme. Auf der waagrechten Achse ist immer die Zeit abgetragen, auf der senkrechten die Prozessoren bzw. Aufgaben.

3.1 Planungsprobleme

Je nachdem, welche Arten von Prozessoren und Aufgaben vorliegen, d. h., welcher Prozes-sor welche Operationen in welcher Zeit bearbeiten kann und unter welchen Bedingungen die zu einem Auftrag geh¨ orenden Operationen abgearbeitet werden m¨ ussen, entstehen mehrere grundlegend verschiedene Kategorien von Planungsproblemen. Zur Beschreibung von Planungsproblemen gibt es in der Ablaufplanung verschiedene Modelle. Ein solches Modell setzt sich aus drei Teilen zusammen (vgl. [Brucker 95], [Blazewicz 96]):

• Dem Auftragsmodell

• Dem Prozessormodell und

7

;;;;;

8 KAPITEL 3. THEORIE DER ABLAUFPLANUNG

;;;;;;;

; ;;; ;; ;; ;; ;; ;; ;;

Abbildung 3.2: Gleiche Belegung wie in Abb. 3.1, jedoch als aufgabenorientiertes Diagramm

• Dem Optimierungskriterium.

Zur kompakten Beschreibung von Planungsproblemen wird eine mathematische Notation benutzt, die auf [Graham 79] zur¨ uckgeht. Sie hat die Form α | β | γ, wobei α die Beschreibung des Prozessormodells, β die Beschreibung des Auftragsmodells und γ die des Optimierungskriteriums ist. Eine genauere Erl¨ auterung der drei Teile dieser Notation und deren Bedeutung findet sich in den folgenden Abschnitten. Soweit nicht anders angegeben, liegen diesen Abschnitten die B¨ ucher [Brucker 95] und [Blazewicz 96] zugrunde.

3.1.1 Auftragsmodelle

Bei jedem Planungsproblem ist eine Menge {A 1 , . . . , A n } von Auftr¨ agen zu bearbeiten. Jeder Auftrag A i besteht aus einer Menge von Operationen O i1 , . . . , O ⁱⁿ i . Besteht der Auftrag nur aus einer Operation, so schreibt man A i statt A i1 .

Der Parameter β eines Planungsproblems beschreibt dessen Auftragsmodell und hat die Form β 1 β 2 β 3 β 4 β 5 . Jeder der f¨ unf Einzelparameter kann entweder leer sein oder einen der Werte, die im folgenden aufgef¨ uhrt sind, haben: listii

• β 1 gibt an, ob die Operationen teilbar (pr¨ aemptiv ) sind.