Diplomarbeit: Software Reengineering (1995)

Der Prozeß des Reengineering am Beispiel eines Studenten-Informationssystems

Diplomarbeit

zur Erlangung des akademischen Grades eines Magisters der Sozial- und Wirtschaftswissenschaften

eingereicht beim

IWI - Institut für Wirtschaftsinformatik Forschungsschwerpunkt Information Engineering

Betreuer: o. Univ.-Prof. Dipl.-Ing. Dr. L. J. Heinrich

von cand. rer. soc. oec. Arno Hütter Matrikelnummer: 9055520 Adresse: J. W. Kleinstraße 46, 4040 Linz Linz, den 22. Februar 1995

Eidesstattliche Erklärung „Ich erkläre an Eides Statt, daß ich die Diplomarbeit mit dem Titel „Der Pro-zeß des Reengineering am Beispiel eines Studenten-Informationssystems“ selbständig und ohne fremde Hilfe verfaßt, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und alle den benutzten Quellen wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht habe.“ 22. Februar 1995 (Arno Hütter)

Inhaltsverzeichnis

Inhaltsverzeichnis I. Einleitung ____________________________________________ 1

I.1 Problemstellung _____________________________________________ 1 I.2 Reengineering ______________________________________________ 1 I.3 Fallstudie __________________________________________________ 2 I.4 Gliederung der Diplomarbeit ___________________________________ 2

II. Grundlagen des Reengineering __________________________ 3

II.1 Begriffsbestimmungen _______________________________________ 3 II.1.1 Reengineering ________________________________________ 4 II.1.2 Reverse-Engineering ___________________________________ 4 II.1.3 Restrukturierung _______________________________________ 4

II.2 Der Prozeß des Reengineering _________________________________ 5 II.3 Die technologische Lücke im Software-Lebenszyklus _______________ 6 II.4 Die Analyse bestehender Anwendungssysteme ____________________ 7 II.5 Restrukturierung ____________________________________________ 9 II.6 Reverse-Engineering _______________________________________ 11 II.7 Allgemeines Vorgehensmodell zum Reengineering ________________ 13 II.8 CARE - Computer Aided Reengineering ________________________ 16

III. Fallstudie __________________________________________ 18

III.1 Die Spezifikation des Zielmodells ____________________________ 18 III.1.1 Datenanforderungen __________________________________ 18 III.1.2 Funktionsanforderungen _______________________________ 18 III.1.3 Benutzerschnittstellenanforderungen _____________________ 19 III.1.4 Technikanalyse ______________________________________ 19

III.2 Die Spezifikation des Ausgangsmodells ________________________ 19 III.2.1 Datenanalyse ________________________________________ 20 III.2.2 Funktionsanalyse ____________________________________ 20

III.2.2.1 Die alte Prozedur Anmeld->Prüf __________________ 21 III.2.2.2 Das neue Skript btnAnmÜbern ___________________ 21

III.2.3 Benutzerschnittstellenanalyse ___________________________ 23 III.3 Die Spezifikation der Erfassungstransformation __________________ 27 III.4 Die Spezifikation der Modelltransformation _____________________ 27 III.5 Die Spezifikation der Realisierungstransformation _______________ 30 III.6 Forward-Engineering ______________________________________ 33

III.6.1 Entwurf ____________________________________________ 33 III.6.1.1 Der Entwurf der Systemarchitektur ________________ 33 III.6.1.2 Der Entwurf der Benutzerschnittstelle _____________ 34

III.6.2 Implementierung _____________________________________ 34

Inhaltsverzeichnis

III.6.3 Test und Installation __________________________________ 35 IV. Benutzerdokumentation ______________________________ 36

IV.1 Systembeschreibung _______________________________________ 36 IV.1.1 Einsatzbereich _______________________________________ 36 IV.1.2 Benötigte Hard- und Softwareressourcen __________________ 36

IV.2 Installationsanleitung ______________________________________ 37 IV.3 Bedienungsanleitung _______________________________________ 38

IV.3.1 Programmstart _______________________________________ 38 IV.3.2 Das Menue Ablage ___________________________________ 39

IV.3.2.1 Der Befehl Über F.I.S.H... _______________________ 40 IV.3.2.2 Der Befehl Logbuch ___________________________ 40 IV.3.2.3 Der Befehl Fehlerprotokoll ______________________ 41 IV.3.2.4 Der Befehl Systemvariablen _____________________ 42 IV.3.2.5 Der Befehl Statistik ____________________________ 43 IV.3.2.6 Der Befehl Beenden ____________________________ 44

IV.3.3 Das Menue Bearbeiten ________________________________ 44 IV.3.4 Das Menue Institut ___________________________________ 45

IV.3.4.1 Der Befehl Personal verwalten ___________________ 45 IV.3.4.2 Der Befehl Personaldaten drucken ________________ 47 IV.3.4.3 Der Befehl Semesterplan verwalten _______________ 48 IV.3.4.4 Der Befehl Semesterplan drucken _________________ 50

IV.3.5 Das Menue Student ___________________________________ 51 IV.3.5.1 Der Befehl Studenten verwalten __________________ 51 IV.3.5.2 Der Befehl Studentendaten drucken _______________ 52 IV.3.5.3 Der Befehl Studienrichtungen verwalten ___________ 55

IV.3.6 Das Menue Lehrveranstaltung __________________________ 56 IV.3.6.1 Der Befehl LVA verwalten_______________________ 56 IV.3.6.2 Der Befehl LVA-Daten drucken __________________ 58 IV.3.6.3 Der Befehl Anwesenheitsliste drucken _____________ 58 IV.3.6.4 Der Befehl LVA-Typen verwalten _________________ 58

IV.3.7 Das Menue Anmeldung ________________________________ 60 IV.3.7.1 Der Befehl Anmeldungsmodus konfigurieren ________ 60 IV.3.7.2 Der Befehl Anmeldungen erfassen ________________ 60 IV.3.7.3 Der Befehl Anmeldungen verwalten _______________ 62 IV.3.7.4 Der Befehl Anmeldeformular drucken _____________ 63 IV.3.7.5 Der Befehl Anmeldeliste drucken _________________ 63 IV.3.7.6 Der Befehl Aufnahmeliste drucken ________________ 63

IV.3.8 Das Menue Prüfung __________________________________ 64 IV.3.8.1 Der Befehl Einstiegsklausuren verwalten ___________ 64 IV.3.8.2 Der Befehl Anmeldeformular drucken _____________ 65 IV.3.8.3 Der Befehl Interne Ergebnisliste drucken ___________ 66

Inhaltsverzeichnis

IV.3.8.4 Der Befehl Externe Ergebnisliste drucken __________ 66 IV.3.8.5 Der Befehl Scheine verwalten ____________________ 66 IV.3.8.6 Der Befehl Interne Ergebnisliste drucken ___________ 68 IV.3.8.7 Der Befehl Externe Ergebnisliste drucken __________ 68 IV.3.8.8 Der Befehl Sammelzeugnis drucken _______________ 69 IV.3.8.9 Der Befehl Diplomprüfungen verwalten ____________ 69 IV.3.8.10 Der Befehl Informationsliste drucken _____________ 70 IV.3.8.11 Der Befehl Ergebnisliste drucken ________________ 70

V. Systemdokumentation ________________________________ 71

V.1 Struktur __________________________________________________ 72 V.1.1 Übersicht ___________________________________________ 72 V.1.2 Die Datei Anmeldung __________________________________ 73 V.1.3 Die Datei Diplomprüfung _______________________________ 73 V.1.4 Die Datei DiplprfgErgeb _______________________________ 73 V.1.5 Die Datei Dummy _____________________________________ 73 V.1.6 Die Datei Einstklsr ____________________________________ 74 V.1.7 Die Datei EinstklsrErgeb _______________________________ 74 V.1.8 Die Datei Fehler ______________________________________ 74 V.1.9 Die Datei Fehlerprotokoll ______________________________ 74 V.1.10 Die Datei Logbuch ___________________________________ 75 V.1.11 Die Datei LVA ______________________________________ 75 V.1.12 Die Datei LVAKürzel _________________________________ 75 V.1.13 Die Datei LVAPlan ___________________________________ 76 V.1.14 Die Datei LVATyp ___________________________________ 76 V.1.15 Die Datei LVAVoraussetzng ____________________________ 77 V.1.16 Die Datei Personal ___________________________________ 77 V.1.17 Die Datei Schein_____________________________________ 77 V.1.18 Die Datei Semester ___________________________________ 78 V.1.19 Die Datei Semesterplan _______________________________ 78 V.1.20 Die Datei Student ____________________________________ 78 V.1.21 Die Datei Studienrichtung _____________________________ 79 V.1.22 Die Datei SystemVar _________________________________ 79 V.1.23 Die Datei Termin ____________________________________ 79 V.1.24 Die Datei Zeittafel ___________________________________ 80

V.2 Layouts __________________________________________________ 81 V.2.1 Übersicht ___________________________________________ 81 V.2.2 Das Layout Anmeldung-Erfassung _______________________ 84

V.2.2.1 Das Skript btnSpeicher __________________________ 84 V.2.3 Das Layout Diplomprüfung-Eingabe ______________________ 86

V.2.3.1 Das Skript btnVrschlgS __________________________ 86

Inhaltsverzeichnis

V.2.4 Das Layout Dummy-Statistik ____________________________ 87 V.2.4.1 Das Skript btnDetail ____________________________ 87

V.2.5 Das Layout LVA-Anmeldung ____________________________ 88 V.2.5.1 Das Skript btnAufnahme _________________________ 88

V.2.6 Das Layout Schein-EingebdLVA _________________________ 91 V.2.6.1 Das Skript NoteGesamt__________________________ 91 V.2.6.2 Das Skript Prüfungsdatum _______________________ 92

V.2.7 Das Layout Semesterplan-Spezifizierung ___________________ 92 V.2.7.1 Das Skript btnEdit _____________________________ 92

V.2.8 Das Layout Student-Eingabe ____________________________ 96 V.2.8.1 Das Skript btnAbbreche _________________________ 96 V.2.8.2 Das Skript btnErster ____________________________ 96 V.2.8.3 Das Skript btnLetzter ___________________________ 96 V.2.8.4 Das Skript btnLöschen __________________________ 96 V.2.8.5 Das Skript btnNächster __________________________ 96 V.2.8.6 Das Skript btnNeu ______________________________ 97 V.2.8.7 Das Skript btnSpeicher __________________________ 97 V.2.8.8 Das Skript btnSuchen ___________________________ 97 V.2.8.9 Das Skript btnVorherig __________________________ 97 V.2.8.10 Das Skript vKennzahl __________________________ 97

V.2.9 Das Layout Student-Suche ______________________________ 98 V.2.9.1 Das Skript btnSuchen ___________________________ 98

V.3 Prozeduren _______________________________________________ 99 V.3.1 Globale Prozeduren ___________________________________ 99

V.3.1.1 Übersicht _____________________________________ 99 V.3.1.2 Die globale Prozedur AktLayVwlAnmldg ___________ 101 V.3.1.3 Die globale Prozedur Auswahl ___________________ 101 V.3.1.4 Die globale Prozedur DruckeStudent ______________ 102 V.3.1.5 Die globale Prozedur ErzgLogEintrag _____________ 102 V.3.1.6 Die globale Prozedur FiltereEreignis ______________ 103 V.3.1.7 Die globale Prozedur FiltereFehler _______________ 103 V.3.1.8 Die globale Prozedur KonfigAnmeldung ___________ 103 V.3.1.9 Die globale Prozedur LVASpezifiziert _____________ 104 V.3.1.10 Die globale Prozedur ÖffneFenster ______________ 105 V.3.1.11 Die globale Prozedur PrüfeBenutzer _____________ 105 V.3.1.12 Die globale Prozedur PrüfeTerminKoll ___________ 105 V.3.1.13 Die globale Prozedur SetzeSystemVar ____________ 107 V.3.1.14 Die globale Prozedur SichereStudent _____________ 107 V.3.1.15 Die globale Prozedur StartUp ___________________ 108 V.3.1.16 Die globale Prozedur VerwltStudent ______________ 109

V.3.2 Layoutprozeduren ___________________________________ 110

Inhaltsverzeichnis

V.3.2.1 Übersicht ____________________________________ 110 V.3.2.2 Die Layoutprozedur LVA-Anmeldung______________ 111 V.3.2.3 Die Layoutprozedur LVA-SammelzgnDrk __________ 112

V.3.3 Dateiprozeduren _____________________________________ 113 V.3.3.1 Übersicht ____________________________________ 113 V.3.3.2 Die Dateiprozedur Anmeldung ___________________ 113

V.4 Menues _________________________________________________ 114 V.5 Kennwörter ______________________________________________ 114

Abbildungsverzeichnis

Abbildungsverzeichnis Abbildung II-1: Der Zusammenhang der Begriffe _______________________ 3 Abbildung II-2: Das klassische Software-Lebenszyklus-Modell ____________ 5 Abbildung II-3: Der Prozeß des Reengineering _________________________ 6 Abbildung II-4: Die technologische Lücke im Software-Lebenszyklus _______ 7 Abbildung II-5: Die Vorgehensweise zur Restrukturierung ________________ 9 Abbildung II-6: Die Vorgehensweise zum Reverse-Engineering (beispielhaft) 12 Abbildung II-7: Beispiele für Ziele, Ergebnisse und Vorgehensweisen zum

Reengineering _____________________________________ 14 Abbildung II-8: Die Architektur von CARE-Werkzeugen ________________ 16 Abbildung III-1: Die Benutzeroberfläche des alten Informationssystems ____ 23 Abbildung III-2: Die Erfassung von Anmeldungen _____________________ 24 Abbildung III-3: Die Verwaltung von Lehrveranstaltungen _______________ 25 Abbildung III-4: Die Ausführung von Prozeduren ______________________ 25 Abbildung III-5: Die Auswahl von Lehrveranstaltungen (1) ______________ 26 Abbildung III-6: Die Auswahl von Lehrveranstaltungen (2) ______________ 26 Abbildung III-7: Das logische Datenmodell des alten Informationssystems __ 27 Abbildung III-8: Das logische Datenmodell des neuen Informationssystems _ 28 Abbildung III-9: Die Benutzeroberfläche des Konvertierungsprogramms ____ 30 Abbildung IV-1: Die Benutzeridentifikation __________________________ 38 Abbildung IV-2: Die Benutzeroberfläche _____________________________ 39 Abbildung IV-3: Das Menue Ablage ________________________________ 40 Abbildung IV-4: Die Verwaltung des Logbuchs _______________________ 41 Abbildung IV-5: Die Statistik ______________________________________ 43 Abbildung IV-6: Das Menue Bearbeiten _____________________________ 44 Abbildung IV-7: Das Menue Institut ________________________________ 45 Abbildung IV-8: Die Verwaltung von Institutspersonal __________________ 46 Abbildung IV-9: Die Standard-Buttons ______________________________ 47 Abbildung IV-10: Die Markierung von Institutspersonal _________________ 48 Abbildung IV-11: Die Verwaltung von Semesterplänen _________________ 49 Abbildung IV-12: Die Bearbeitung von Semesterplänen _________________ 50 Abbildung IV-13: Das Menue Student _______________________________ 51 Abbildung IV-14: Die Verwaltung von Studenten ______________________ 51 Abbildung IV-15: Die Suche nach Studenten __________________________ 52 Abbildung IV-16: Die Markierung von Studenten ______________________ 53 Abbildung IV-17: Die Auswahl von Lehrveranstaltungen ________________ 54 Abbildung IV-18: Die Auswahl von Drucklayouts ______________________ 55 Abbildung IV-19: Die Verwaltung von Studienrichtungen _______________ 55 Abbildung IV-20: Das Menue Lehrveranstaltung ______________________ 56 Abbildung IV-21: Die Verwaltung von Lehrveranstaltungen ______________ 57

Abbildungsverzeichnis

Abbildung IV-22: Die Verwaltung von Lehrveranstaltungstypen __________ 59 Abbildung IV-23: Das Menue Anmeldung ____________________________ 60 Abbildung IV-24: Die Erfassung von Anmeldungen ____________________ 61 Abbildung IV-25: Die Verwaltung von Anmeldungen ___________________ 62 Abbildung IV-26: Das Menue Prüfung _______________________________ 64 Abbildung IV-27: Die Verwaltung von Einstiegsklausuren _______________ 65 Abbildung IV-28: Die Verwaltung von Scheinen _______________________ 67 Abbildung IV-29: Die Bestimmung von Lehrveranstaltung, Fachrichtung und

Prüfungsdatum ___________________________________ 68 Abbildung IV-30: Die Verwaltung von Diplomprüfungen ________________ 69 Abbildung V-1: Das physische Datenmodell __________________________ 72

Tabellenverzeichnis

Tabellenverzeichnis Tabelle II-1: Ein Vergleich von CARE-Tools _________________________ 17 Tabelle III-1: Die relevanten Modelltransformationen ___________________ 29 Tabelle III-2: Die alte Datei LVA_Jahr _______________________________ 31 Tabelle III-3: Die neue Datei LVA __________________________________ 32 Tabelle III-4: Die neue Datei LVATyp _______________________________ 32 Tabelle III-5: Die neue Datei Personal _______________________________ 33 Tabelle IV-1: Die Systemvariablen __________________________________ 42 Tabelle V-1: Die Datei Anmeldung __________________________________ 73 Tabelle V-2: Die Datei Diplomprüfung ______________________________ 73 Tabelle V-3: Die Datei DiplprfgErgeb _______________________________ 73 Tabelle V-4: Die Datei Dummy _____________________________________ 73 Tabelle V-5: Die Datei Einstklsr ____________________________________ 74 Tabelle V-6: Die Datei EinstklsrErgeb _______________________________ 74 Tabelle V-7: Die Datei Fehler _____________________________________ 74 Tabelle V-8: Die Datei Fehlerprotokoll ______________________________ 74 Tabelle V-9: Die Datei Logbuch ____________________________________ 75 Tabelle V-10: Die Datei LVA ______________________________________ 75 Tabelle V-11: Die Datei LVAKürzel _________________________________ 75 Tabelle V-12: Die Datei LVAPlan __________________________________ 76 Tabelle V-13: Die Datei LVATyp ___________________________________ 76 Tabelle V-14: Die Datei LVAVoraussetzng ___________________________ 77 Tabelle V-15: Die Datei Personal ___________________________________ 77 Tabelle V-16: Die Datei Schein ____________________________________ 77 Tabelle V-17: Die Datei Semester ___________________________________ 78 Tabelle V-18: Die Datei Semesterplan _______________________________ 78 Tabelle V-19: Die Datei Student ____________________________________ 78 Tabelle V-20: Die Datei Studienrichtung _____________________________ 79 Tabelle V-21: Die Datei SystemVar _________________________________ 79 Tabelle V-22: Die Datei Termin ____________________________________ 79 Tabelle V-23: Die Datei Zeittafel ___________________________________ 80 Tabelle V-24: Layouts (Übersicht) __________________________________ 84 Tabelle V-25: Globale Prozeduren (Übersicht) _______________________ 101 Tabelle V-26: Layoutprozeduren (Übersicht) _________________________ 111 Tabelle V-27: Dateiprozeduren (Übersicht) __________________________ 113 Tabelle V-28: Menueleisten ______________________________________ 114

Einleitung 1

I. Einleitung I.1 Problemstellung Die hohe und noch immer steigende Nachfrage nach Anwendungssystemen zur Befriedigung betrieblicher Informationsbedarfe verlangt nach allgemein ein-setzbaren Lösungsansätzen im Bereich der Programmentwicklung und -wartung. Schlagworte wie Anwendungsstau, Altlasten und Wiederverwend-barkeit prägen die gegenwärtige Diskussion um die software-technischen Pro-bleme in der Praxis. Für den Fall eines vollständigen System-Neuentwurfs exi-stieren eine Reihe von theoretisch ausgiebig fundierten Konzepten, an deren Umsetzung in die betriebliche Realität im Moment mit Nachdruck gearbeitet wird. Im Gegensatz dazu gestaltet sich die Software-Wartung um einiges schwieriger, nicht zuletzt dadurch, daß die rasant fortschreitende technologische Entwicklung zu einer ebenso raschen Veralterung bestehender Systeme führt.1 Konkrete Anlässe für das Notwendigwerden einer grundlegenden Überarbei-tung können u.a. sein:2 • Unstrukturierter Code • Fehlende Dokumentation • Unvollständige Funktionalität • Abhängigkeit von der Umgebung I.2 Reengineering Ausgehend von der geschilderten Problemstellung ist die Zielsetzung des Reengineering in seiner weitesten Definition die Untersuchung, Analyse und Veränderung eines Systems, um es in neuer Form und/oder Umgebung wieder zu implementieren. Dies beinhaltet: 3 • Die Darstellung des Systems auf höherer Abstraktionsebene • Die technische Optimierung auf gleicher Stufe • Die Beschreibung der Komponenten und deren Beziehungen • Einen erneuten Entwicklungsprozeß

1Vgl. Kaufmann, A.: „Software-Reengineering“, S. 1 2Vgl. Bischoff, Krallmann: „Reengineering“, S. 125 3Vgl. ebenda

Einleitung 2

I.3 Fallstudie Am Institut für Wirtschaftsinformatik/IE der Johannes-Kepler-Universität Linz war seit 1989 ein Informationssystem im Einsatz, mit dessen Hilfe die wichtig-sten Daten rund um das Studentenwesen verwaltet werden konnten. Diese An-wendung wurde unter anderen Planungsprämissen implementiert und vermochte die heutigen Anforderungen nicht mehr adäquat zu erfüllen. Zahlreiche an sich automatisierbare Tätigkeiten mußten weiterhin manuell durchgeführt werden. Besonders die in vielerlei Hinsicht mangelnde Flexibilität der Datenbank fiel dabei negativ ins Gewicht. Desweiteren erschien auch eine komplette Überar-beitung der Benutzerschnittstelle wünschenswert. In Zusammenarbeit mit den späteren Benutzern (das waren im gegebenen Fall v.a. Lehrveranstaltungsleiter und Sekretariat des Instituts) wurden die Erwart-ungen an das zu schaffende Informationssystem präzisiert und untereinander abgestimmt. Mittels einer eingehenden Untersuchung der existierenden Appli-kation konnten Stärken und Schwächen des Istzustandes sowie bestehende Sy-stemgrenzen erfaßt werden. Auf diese Weise waren auch Rückschlüsse auf eine mögliche Wiederverwendbarkeit von Daten und Programmteilen der alten Ver-sion möglich. Anschließend erfolgte der Neuentwurf von Datenmodell und Sy-stemarchitektur. Nach abgeschlossener Implementierung sowie der Durchfüh-rung von Komponenten- und Systemtests, wurden die vorhandenen Daten kon-vertiert und notwendig gewordene Abschlußarbeiten vorgenommen. I.4 Gliederung der Diplomarbeit In Kapitel II werden Begriffsbestimmungen und -abgrenzungen vorgenommen, die Grundlagen des Reengineering behandelt sowie ein allgemein anwendbares Vorgehensmodell vorgestellt. Darauf aufbauend erläutert Kapitel III die Gege-benheiten des konkreten Fallbeispiels und die entsprechend angepaßte Vorge-hensweise. In Kapitel IV wird das Endprodukt des Reengineering-Prozesses aus Benutzersicht beschrieben, während Kapitel V eine Dokumentation des Soft-ware-Systems beinhaltet, welche die Grundlage für zukünftige Wartungs- und Weiterentwicklungstätigkeiten bildet.

Grundlagen des Reengineering 3

II. Grundlagen des Reengineering II.1 Begriffsbestimmungen Das Schlagwort des Reenginering kursierte erstmals Anfang der siebziger Jah-re als mögliche Antwort auf das sich ständige verschärfende Problem der Soft-ware-Wartung. In diesem relativ diffusen Terminus spiegelten sich Hoffnungen und Wünsche der DV-Anwender wie potentielle Marktchancen für Anbieter aus diesem Bereich gleichermaßen wider. In verschiedenen Veröffentlichungen neueren Datums wird Reengineering zunehmend als generalisierender Oberbeg-riff verwendet. Abbildung II-1 verdeutlicht die Zusammenhänge zwischen den oft recht widersprüchlich verwendeten Vokabeln rund um das Reengineering.

Integration

AdaptionExtraktionAbstraktion

RE-USE(umfassend)

RE-USE(eingeschränkt)

RE-ENGINEERING

Restrukturierung und Redesign

Neue SW-Systeme

Existierende SW-SystemeREVERSE

ENGINEERING

Wiederbenut.Komponenten Identifikation

Selektion

Inte-gra-tion

Resultierende SW-Systeme

Repositorium

Abbildung II-1: Der Zusammenhang der Begriffe4

4Vgl. Richter, L.: „Wiederbenutzbarkeit und Restrukturierung oder Reuse, Reengineering und Reverse Engineering“, S. 128


II.1.1 Reengineering „Ziel des Reengineering ist es, Wirksamkeit und Wirtschaftlichkeit einer be-stehenden Informationsinfrastruktur durch den Einsatz qualitativ besserer Kon-zepte und Technologien zu erhöhen.“5 Es wird nicht nur versucht, bestehende in verbesserte physische Anwendungssysteme zu überführen, sondern auch kon-zeptuelle Modelle aus vorhandenen Realisierungen abzuleiten.6 Reengineering umfaßt sowohl die Beseitigung noch vorhandener Fehler in frühen Betriebspha-sen als auch die nachträgliche Anpassung an erweiterte oder geänderte funktio-nale und qualitative Anforderungen. II.1.2 Reverse-Engineering Als Reverse-Engineering wird der Prozeß der Analyse eines installierten Sy-stems bezeichnet, der das Ziel hat, die Grundlagen für den Entwurf dieses Sy-stems wiederzubeschaffen.7 Dies geschieht üblicherweise auf Basis vorhandener Quellcodes. Die so ermittelten Kontroll- und Datenstrukturinformationen wer-den in einem Repositorium abgelegt, einem Datenkatalog-System, das die spä-tere Wiederverwendung einzelner Komponenten ermöglicht.8 II.1.3 Restrukturierung Von Restrukturierung spricht man, wenn qualitätsverbessernde Maßnahmen hinsichtlich der Systemstruktur ohne Tangierung der bestehenden Funktionalität des Software-Produkts oder eine Anpassung an neue Basistechnologien im Vordergrund stehen.9

5Reindl, M.: „Re-Engineering des Datenmodells“, S. 282 6Vgl. ebenda 7Vgl. Heinrich, Roithmayer: „Wirtschaftsinformatik-Lexikon“, S. 446 8Vgl. Richter, a.a.O, S. 128 9Vgl. Frazer, A.: „Reverse-Engineering - hype, hope or here?“, S. 215


II.2 Der Prozeß des Reengineering Ausgangspunkt aller Betrachtungen in Hinblick auf den Prozeß des Reengineering ist - unabhängig von den verschiedenen Ansätzen wie Wasser-fallmodell, Spiralmodell, usw. - der Software-Lebenszyklus. Hier stellt sich die Frage, inwieweit sich Reengineering auf derselben methodischen Basis definie-ren läßt oder sogar Bestandteil des Software-Entwicklungsprozesses ist.10

Problemstellung

Problemanalyse

Systemspezifikation

System- und Komponentenentwurf

Betrieb und Wartung

Systemtest

Implementierung und Komponententest

Datenmodell, Systemarchitektur,algorithmische Struktur der Systemkomponenten

Benutzerwünsche

Pflichtenheft,(Systemspezifikation)

Projektideeneue Anforderungen

Endprodukt

Programme,Dokumentation

Abbildung II-2: Das klassische Software-Lebenszyklus-Modell11

Reengineering-Projekte können auf jeder der dargestellten Abstraktionsebenen ansetzen, um eine alte in eine neue Systemrepräsentation der selben oder einer anderen Ebene zu überführen. Eine Restrukturierung betrifft die Anpassung existierender Strukturen an neue Gegebenheiten oder Bedürfnisse, bei der eine Migration eines Ausgangs- in ein Zielsystem auf gleicher Ebene stattfindet. Reverse-Engineering bzw. Redesign beziehen sich dagegen immer auf zwei

10Vgl. Kaufmann, A.: a.a.O, S. 10 11Pomberger, Blascheck: „Software Engineering“, S. 18


verschiedene Ebenen. Komplexere Reengineering-Prozesse kombinieren meist Tätigkeiten der Restrukturierung, des Reverse-Engineering und auch solche, die bei einer Systemneuentwicklung anfallen würden (Forward-Engineering).12

Pflichtenheft Systemarchitektur,Datenmodell

Komponenten-struktur

Programme,Dokumentationen

Restruk-turierung

Abstraktionsebenen

Forward-Engineering

Reverse-Engineering

Systementwurf

Redesign

Restruk-turierung

Komponentenentwurf

Redesign

Restruk-turierung

Implementierung

Redesign

Restruk-turierung

ÜberführungSystemspezifikation

Abbildung II-3: Der Prozeß des Reengineering13

II.3 Die technologische Lücke im Software-Lebenszyklus Das aus allen Wirtschaftszweigen bekannte Phänomen des Technologie-Gaps tritt in der Software-Entwicklung aufgrund starken Innovationsdrucks und ver-kürzter Lebenszyklen im Technikbereich verschärft zu Tage. Software-Produkte hingegen verbleiben meist auf dem Stand ihrer Erstentwicklung und leben deut-lich länger als die Technologie, auf der sie basieren.14

12Vgl. Kaufmann, A.: a.a.O, S. 8f 13Vgl. ebenda, S. 10 14Vgl. Thurner, R.: „ReEngineering und Innovation in der Anwendungsentwick-lung“, S. 39f


Technologische Lücke

Technologieschub

Reengineering

Risiko

Implementierung

Wartung Entwurf

Technologieschub

Technologie

Software-Produkt

Abbildung II-4: Die technologische Lücke im Software-Lebenszyklus15

Mit fortschreitender Lebensdauer wird die Notwendigkeit des Reengineering als Maßnahme der Anhebung des software-technischen Levels zur Schließung der Lücke immer offensichtlicher. II.4 Die Analyse bestehender Anwendungssysteme Die Analyse bestehender Anwendungssysteme ist die Grundlage jedes Reengineering-Vorhabens. Prinzipiell können sämtliche Software-Qualitätsmerkmale wie Korrektheit, Zuverlässigkeit oder Benutzbarkeit Gegen-stand einer derartigen Untersuchung sein, aus einleuchtenden Gründen stehen aber zumeist die Kriterien der Wartbarkeit und Übertragbarkeit im Mittel-punkt des Interesses. Diesbezüglich sind v.a. die Vollständigkeit der vorhande-nen Systeminformationen und deren Repräsentationseignung im Hinblick auf die jeweilige Wartungsaufgabe von entscheidender Bedeutung. So wie Reengineering-Maßnahmen unterschiedliche Aspekte eine Softwaresystems be-treffen können, existiert auch eine Vielzahl von Analysemöglichkeiten.

15Vgl. Thurner, R.: a.a.O, S. 40


Die wichtigsten Inhalte und Methoden der Programmanalyse lassen sich fol-gendermaßen zusammenfassen:16 • Vollständigkeitsanalyse • Konsistenzanalyse • Zweckanalyse • Bestandteilsanalyse • Operationsanalyse • Stilanalyse • Komplexitätsanalyse Im Rahmen einer Vollständigkeitsanalyse wird untersucht, inwieweit Entwick-lungs-, Benutzungs- und Wartungsdokumente für das Softwaresystem in ausrei-chendem Maße vorliegen oder ohne nennenswerten zeitlichen und finanziellen Aufwand erzeugt werden können. Die Konsistenzanalyse soll Aufschlüsse in Hinblick auf die Widerspruchsfreiheit der Systembeschreibungen zulassen. Ein in der Praxis häufig anzutreffendes Problem ist dabei die mangelhafte Abstim-mung zwischen Systemrepräsentationen verschiedener Abstraktionsebenen. Die Zielsetzung der Zweckanalyse ist die Ableitung der spezifischen Zweckbe-stimmung einzelner Programmkomponenten. In der Bestandteilsanalyse wer-den besonders relevante Teilsysteme aus einer bisher gesamtheitlichen Betrach-tung herausgelöst und näher untersucht. Gegenstand der Operationsanalyse ist die Offenlegung der Arbeitsweise einzelner Systembereiche. Die Stilanalyse dient der Überprüfung auf eine konsequente Anwendung von Programmierstan-dards und der Konsistenz des Stils. In der Komplexitätsanalyse wird die logi-sche Kompliziertheit der Programmstrukturen untersucht.

16Vgl. Kaufmann, A.: a.a.O, S. 24ff


II.5 Restrukturierung Primäres Ziel der Restrukturierung ist eine Erhöhung der Wartungsproduktivi-tät, indem die Verständlichkeit der Systemstrukturen durch Transformation von Beschreibungsarten und -formen verbessert wird. Dabei kommen grundsätzlich zwei verschiedene Vorgehensweisen in Frage:17 • Direkte Umsetzung (Translation und Optimierung) • Mittelbare Umsetzung (Abstraktion und Reimplementierung)

Logische Ebene

Physische Ebene

ReimplementierungAbstraktion

Translation OptimierungAusgangs-system

ZielsystemZwischen-

code

AbstraktesModell

Abbildung II-5: Die Vorgehensweise zur Restrukturierung18

Bei der direkten Umsetzung wird jedes Element des Ausgangssystems (ggf. unter Verwendung eines Zwischenmodells) in ein entsprechendes Zielstruktur-element ohne Kontextbezug eins zu eins übertragen. Die mittelbare Umset-zung hingegen verlangt in einem ersten Schritt die globale Analyse des Aus-gangssystems um zu einer abstrakten Beschreibung ohne Berücksichtigung syn-taktischer Gegebenheiten zu gelangen. Diese Beschreibung kann dann in die Strukturen des Zielmodells transformiert werden.

17Vgl. ebenda, S. 32f 18Ebenda, S. 33


In Anlehnung an die Komponenten eines Anwendungssystems lassen sich fol-gende Objekte einer möglichen Restrukturierung anführen:19 • Restrukturierung von Code • Restrukturierung von Programm- und Systemstrukturen • Restrukturierung von Daten • Restrukturierung von Benutzeroberflächen • Restrukturierung von Anwendungsfunktionen • Restrukturierung von Plattformen Restrukturierung von Code ist ein in der Regel recht aufwendiger Vorgang, selbst bei einer Migration zwischen zwei verschiedenen Standards ein und der-selben Programmiersprache. In den meisten Fällen soll jedoch Code mit hohem Technikbezug in Code mit hohem Anwendungsbezug umgesetzt, also eine Übertragung einer Sprache einer niedrigen in eine höhere Generation vollzogen werden. Neben diesen Sprachumsetzern sind auch Restrukturierungswerkzeuge, die beispielsweise die Eliminierung von GOTO-Anweisungen vornehmen, im Einsatz. Bei der Restrukturierung von Programm- und Systemstrukturen wird ver-sucht, die Systemarchitektur unter Beibehaltung der Anwendungsfunktionalität zu verändern. Die Restrukturierung von Daten hat die Gewinnung des Datenmodells aus bestehenden Datendefinitionen zum Inhalt, um dieses ebenso wie Datenhal-tungssystem und Anwendungssystem bereinigen zu können. Der Ansatz der Restrukturierung von Benutzeroberflächen besteht darin, durch Frontending bestehende Anwendungen mit einer neuen Benutzeroberf-läche zu versehen, um damit die Funktionalität technisch ansonsten brauchbarer Systeme leichter zugänglich zu machen. Charakteristisch dafür ist heute die Migration zeichen- oder blockorientierter Benutzerschnittstellen zentraler Ar-beitsrechner zu graphisch orientierten Oberflächen. Eine Restrukturierung von Anwendungsfunktionen stellt meist eine sehr an-spruchsvolle Architekturaufgabe, aber auch eine im Vergleich zu Neuentwick-lungs-Großprojekten sinnvolle und mit weniger Risiken behaftete Alternative

19Vgl. Thurner, R.:a.a.O, S. 45ff


dar. Der Übergang von der Unterstützung einzelner Aufgaben hin zu einem ge-schäftsfallorientierten System wäre ein Beispiel dafür. Bei der Restrukturierung von Plattformen - man spricht in diesem Zusammenhang auch von Portierung - wird ein koordinierter Übergang von einer bestehenden auf eine Zielplattform (sei es nun bezüglich Rechnerarchitek-tur oder Betriebssystem, etc.) angestrebt. Das Ergebnis dieses Prozesses kann entweder in einem ebensowenig portablen System auf neuer Plattform liegen (für diesen Fall sind umfangreiche Praxiserfahrungen vorhanden), oder aber - wenngleich mit erheblichen Mehraufwand verbunden - in einem nunmehr por-tablen System. Ein weiteres Teilgebiet der Restrukturierung ist die Redokumentation von Programmen. Eine vollständige und konsistente Dokumentation ist eine der wesentlichsten Voraussetzungen für die Effizienz von Wartungsarbeiten. Dabei lassen sich folgende Vorgehensweisen unterscheiden:20 • Transformation in eine andere Darstellungsweise • Generierung nicht vorhandener Dokumentationen • Extrahierung und Aufbereitung von Teilsichten (Program-Slicing) II.6 Reverse-Engineering „Reverse-Engineering dient der Steigerung der Wartungsproduktivität, indem die Verständlichkeit der Programme durch Extraktion der Systembeschreibun-gen konzeptionell höherliegender Abstraktionsebenen aus den Strukturen einer tieferen, meist technologisch beeinflußten Ebene verbessert wird.“21 Somit er-möglichen diese Darstellungen eine wesentliche Aufwandsminderung bei der Neuentwicklung existierender Systeme, wenn mit Hilfe geeigneter Methoden und Werkzeuge auf den Strukturbeschreibungen des Altsystems aufgebaut wird oder brauchbare Teile direkt übernommen werden können.

20Vgl. Kaufmann, A.: a.a.O, S. 34f 21Ebenda, S. 45


Komponenten-struktur

Programme,Dokumentationen

Abstraktionsebenen

Forward-Engineering

Reverse-Engineering

Redesign

Zwischen-modell

Überführung

Ziel-system

Ausgangs-system

Implementierung

Abbildung II-6: Die Vorgehensweise zum Reverse-Engineering (beispielhaft)22

Reverse-Engineering bezieht sich immer auf verschiedene Abstraktionsebenen, während die dabei extrahierten Systembeschreibungen normalerweise nicht ebenenübergreifend sind. So werden etwa auf Spezifikationsebene Daten mit Hilfe von Entity-Relationship-Diagrammen und Funktionen durch hierarchische Dekomposition dargestellt, wohingegen auf Implementierungsebene Dateibe-schreibungen und Programmiersprachen zum Einsatz kommen. Die besondere Problematik liegt darin, daß bestimmte - etwa im Rahmen der Anforderungsana-lyse erhobene - Sachverhalte im Laufe der Gesamtentwicklung verlorengegan-gen sind oder strukturell so verändert wurden, daß eine Rückabbildung nicht mehr möglich ist. In so einem Fall müssen zusätzliche Informationen beschafft werden, um eindeutige Rückschlüsse zuzulassen. Zwei Teilbereiche des Reverse-Engineering können unterschieden werden:23 • Reverse-Engineering von Daten • Reverse-Engineering von Funktionen

22Vgl. ebenda, S. 34 23Vgl. ebenda, S. 45f


Beim Reverse-Engineering von Daten kommt es zu einer Übertragung tech-nisch orientierter Datenstrukturen auf höhere Ebene, beispielsweise von hierar-chischen Dateibeschreibungen auf eine konzeptionelle Datenmodellebene. De-rartige Vorgehensweisen sind schon seit längerem Gegenstand der wissen-schaftlichen Diskussion und auch in der Praxis im Einsatz. Das Reverse-Engineering von Funktionen gestaltet sich durch einen oftmals eklatanten Strukturbruch zwischen Programmquellen und Architektur- bzw. Komponentendesign ungleich schwieriger. So finden sich auch in der Literatur nur wenige Ansätze zum Reverse-Engineering von Funktionen der über dem Programmdesign liegenden Abstraktionsebenen. II.7 Allgemeines Vorgehensmodell zum Reengineering Bei der Entwicklung einer universell einsetzbaren Verfahrensweise muß - ange-sichts der Vielfalt obig beschriebener Reengineering-Maßnahmen - eine Ab-straktion von konkreten Gegebenheiten vorgenommen und auf Komponenten und Strukturen aufgebaut werden, die allen Reengineering-Konzepten gemein-sam sind.


Für jedes ökonomisch motivierte Vorgehen muß eine klare Ziel-Ergebnis-Vorgehensweise-Struktur formuliert werden.

Ziel

Ergebnis

Vorgehen

Hoher Wartbarkeitsgrad

Lesbare Programmquellen

VollständigeDokumentation

Strukturierte Kontrollelemente

Verfahren von Mills

Fachliches Datenmodell

Verfahren von Navathe

Abbildung II-7: Beispiele für Ziele, Ergebnisse und Vorgehensweisen zum Reengineering24

Ein Ziel kann durch ggf. unterschiedliche Ergebnisse erreicht werden; die Er-gebnisse resultieren wiederum aus verschiedenen Vorgehensweisen. Die Palette an potentiellen Vorgehensweisen wird durch die jeweiligen situationsspezifi-schen Rahmenbedingungen eingeschränkt. Im Falle von Reengineering-Vorhaben sind dies v.a. die Informationsbestände in Form von Altsystemen.25

24Vgl. ebenda, S. 81 25Vgl. ebenda, S. 78ff


Ausgehend von diesen Grundgedanken leitet Kaufmann folgende Schritte einer Basisvorgehensweise ab:26 • Spezifikation des Zielmodells • Spezifikation des Ausgangsmodells • Spezifikation der Erfassungstransformation • Spezifikation der Modelltransformation • Spezifikation der Realisierungstransformation Die Spezifikation des Zielmodells erfolgt durch eine Untersuchung der rele-vanten Elemente und Beziehungen und deren Darstellung in geeigneter Form. Bei der Spezifikation des Ausgangsmodells sind eine zielmodellorientierte (Bewertung von Komponenten und Strukturen des Ausgangssystems hinsicht-lich der Relevanz für jedes einzelne Informationsobjekt und jede Beziehung des Zielmodells) und eine zielmodellneutrale Vorgehensweise (Erkennung von Komponenten und Strukturen des Ausgangssystems unabhängig von speziellen Zielmodellen) denkbar. Unter der Spezifikation der Erfassungstransformati-on wird die Identifizierung und Integrierung von Bestandteilen des Ausgangs-systems zu Objekten des Ausgangsmodells verstanden. Um aus den Informatio-nen des Ausgangsmodells Zielmodellinhalte generieren zu können, sind im Rahmen der Spezifikation der Modelltransformation die relevanten Trans-formationsprozesse zu ermitteln. Die Spezifikation der Realisierungstrans-formation ist eine in der Regel schablonenartige Umsetzung der Modelltrans-formationen, u.U. können aber auch wesentlich verkomplizierte Transformati-onsalgorithmen entstehen.

26Vgl. ebenda, S. 82ff


II.8 CARE - Computer Aided Reengineering Ansätze zum computerunterstützten Reengineering lassen sich erstmals bei ei-nigen Mitte der siebziger Jahre erschienenen Restrukturierungswerkzeugen er-kennen. Das Programm Structure Engine etwa eliminierte GOTO-Anweisungen aus unstrukturierten FORTRAN -Programmen und ersetzte diese durch standardisierte Prozeduraufrufe. Die seither entwickelten Werkzeuge er-möglichen sowohl die Überarbeitung kommerzieller Anwenderprogramme als auch spezifischer Systemsoftware. Ihnen allen ist gemeinsam, daß sie zwar for-male Neugestaltungen eigenständig durchführen, jedoch keinerlei funktionale Änderungen oder Erweiterungen vornehmen können. Es erfolgt lediglich eine Transformation eines Ausgangssystems, das auf alten Technologien aufbaut oder aus überholten Strukturen besteht, in ein neues, äquivalentes System.27

Parser,Semant. Analysator

Datenbasis

View-Composer

An-wen-

dungs-system

Produkt

Neue Darstellungsformen oder Produktsichten

(Views)

· Format· Grafik· Dokumentation· Metrik· Reports

Abbildung II-8: Die Architektur von CARE-Werkzeugen28

27Vgl. Heinrich, Lehner, Roithmayr: „Informations- und Kommunikationstech-nik“, S. 334 28Ebenda


Tabelle II-1 enthält einen exemplarischen Vergleich dreier willkürlich gewähl-ter CARE-Tools.

INNOVATOR SE/ Design Recovery

ROCHADE

Allgemeines Anzahl Installationen 1660 780 Entwicklungssprache C C, ORIF, RSI C Oberfläche MS Windows MS Windows MS Windows Zielsprachen C, PASCAL,

FORTRAN, PL/M COBOL zielsprachenunabhän-

gig Stärken • Client-Server-

Konzept • Standardmethoden

(SA/RT, SD, IM) • Kontextsensitive

Menueführung

• Verwendungs-nachweis von Da-tenelementen

• Erkennen poten-tieller Synonyme

• Erzeugung der Modulaufrufhierar-chie

• Absolut flexibles Werkzeug, das sich den Bedürf-nissen des jeweili-gen Unternehmens anpaßt

Unterstützung Beschreibungsmittel SA/RT, SD, IM, ER methodenneutral, für

alle gängigen Metho-den konfigurierbar

Redokumentation nein ja ja Restrukturierung ja ja nein Reengineering ja ja ja Überarbeitung Systemarchitektur nein ja ja Prozeduren/Module ja ja ja Programmsteuerung ja ja ja Datenzugriffe nein ja ja Präsentationsschicht nein ja ja Benutzeroberfläche nein ja ja

Tabelle II-1: Ein Vergleich von CARE-Tools29

29Vgl. Krallmann, Wöhrle: „Marktübersicht CARE-Tools“, S. 183ff

Fallstudie 18

III. Fallstudie III.1 Die Spezifikation des Zielmodells Zu Beginn des Projekts wurden vom Auftraggeber - in Kenntnis der Schwächen der bestehenden Applikation - erste globale Anforderungen an das zu schaffen-de Informationssystem formuliert. Diese beinhalteten v.a. den Wunsch nach mehr Flexibilität und einer Ausweitung des Funktions- und Datenangebots rund um das Studentenwesen. Die Spezifizierung des Sollzustandes erfolgte bereits in diesem Stadium in gewissem Rahmen unter Berücksichtigung der besonderen Gegebenheiten des Istzustandes. In weiterer Folge konnten in einem zyklischen Prozeß zusammen mit Assisten-ten und Sekretariat des Instituts die geäußerten Erwartungen näher präzisiert werden. Einige neue Anforderungen wurden auch erst später nach dem Vorlie-gen eine ersten Prototypen im Wissen um deren technische Machbarkeit artiku-liert. III.1.1 Datenanforderungen Als wichtigste Objekttypen des zukünftigen Datensystems wurden identifiziert: • Studenten • Lehrveranstaltungen • Personal • Anmeldungen • Einstiegsklausuren • Scheine • Diplomprüfungen III.1.2 Funktionsanforderungen Das ursprünglich vorgesehene Funktionsgerüst umfaßte die Punkte • Verwaltung von Studenten • Verwaltung von Lehrveranstaltungen • Verwaltung von Lehrveranstaltungsleitern • Verwaltung von Einstiegsklausuren

Fallstudie 19

• Flexibel konfigurierbare Anmeldungserfassung • Automatisches Aufnahmeverfahren • Verwaltung von Scheinen • Verwaltung von Diplomprüfungen • Erstellung von Notenvorschlägen für Diplomprüfungen • Druck von Stammdaten • Druck von Anmeldelisten • Druck von Ergebnislisten • Druck von Informationslisten Später traten noch weitere Anforderungen hinzu: • Generierung von Semesterplänen • Statistische Datenauswertung • Führung eines Logbuchs • Führung eines Fehlerprotokolls III.1.3 Benutzerschnittstellenanforderungen Die Gestaltung der Benutzerschnittstelle sollte nach ergonomischen Erkenntnis-sen erfolgen und in sich konsistent sein. Diesbezüglich konnte relativ rasch ein Prototyp vorgestellt und für geeignet befunden werden. III.1.4 Technikanalyse Die Wahl der Implementierungsumgebung war nicht nur durch das Altsystem, sondern allein schon aufgrund der hard- und softwaretechnischen Ressourcen am Institut für Wirtschaftsinformatik praktisch vorweggenommen. Es handelte sich dabei um das Viert-Generationswerkzeug 4th Dimension, das zu Projekt-beginn in der Version 3.0 vorlag. III.2 Die Spezifikation des Ausgangsmodells Ziel der Analyse des bis dato im Einsatz befindlichen Informationssystems war die Aufdeckung der spezifischen Stärken und Schwächen, um Rückschlüsse auf

Fallstudie 20

eventuell wiederverwendbare Komponenten und zukünftige Entwicklungspo-tentiale zu gewinnen. III.2.1 Datenanalyse Das Altsystem beinhaltete folgende Daten-Objekttypen: • Studenten • Lehrveranstaltungen • Einstiegsklausuren • Anmeldungen • Scheine Unangenehm bemerkbar machten sich dabei einige kleinere Redundanzen und daraus resultierende Inkonsistenzen. Das Volumen des Datenbestandes war trotz der wenigen Dateien im Laufe der Zeit erheblich angewachsen (mehrere MegaByte), sodaß die Notwendigkeit einer Datenkonvertierung - verbunden mit einer kompletten Restrukturierung - von vornherein feststand. III.2.2 Funktionsanalyse Nachstehende Funktionen wurden (teilweise auf Umwegen - siehe weiter unten) durch das bestehenden Informationssystem bereitgestellt: • Verwaltung von Studenten • Verwaltung von Lehrveranstaltungen • Verwaltung von Einstiegsklausuren • Verwaltung von Scheinen • Erfassung von Anmeldungen • Druck von Anmeldelisten • Druck von Sammelzeugnissen Programmarchitektur und -komponenten konnten als einwandfrei strukturiert bezeichnet werden, dennoch wurde bereits frühzeitig deutlich, daß aufgrund der Weiterentwicklung der Implementierungssprache innerhalb der letzten fünf Jah-

Fallstudie 21

re und der teilweise völlig neuartigen Anforderungen ein komplettes Reengineering der Funktionsstruktur nicht zweckmäßig war. Auch die Restrukturierung wenig komplexer Systemkomponenten gestaltete sich problematisch. Dieser Umstand soll beispielhaft anhand der Prozedur An-meld->Prüf und deren „Nachfolger“ im neuen Informationssystem deutlich ge-macht werden. III.2.2.1 Die alte Prozedur Anmeld->Prüf Besagte Prozedur übernahm vorhandene Anmeldungen einer noch vom Benut-zer zu spezifizierenden Lehrveranstaltung und transformierte diese in Scheine, wodurch unnötiger Erfassungsaufwand vermieden werden konnte. $LVA:=Num(Request("Eingabe: Surrogat für die LVA")) SEARCH BY INDEX([LVA_Jahr]Sur_LVA=$LVA) If (Records in selection([LVA_Jahr])=1) CONFIRM("Teilnehmerliste für die LVA "+[LVA_Jahr] LVA_Name+", "+ [LVA_Jahr]Sem_Jahr+", "+[LVA_Jahr]LVA_Leiter+ ", LVA-Nr: "+[LVA_Jahr]LVA_Nr) If (OK=0) ABORT End if Else ALERT("Diese LVA existiert nicht") ABORT End if DEFAULT FILE([Anmeldung_Neu]) FIRST RECORD While (Not(End selection)) SEARCH BY INDEX([Prüfungen]Matr_Nr=[Anmeldung_Neu ]Matr_Nr) SEARCH SELECTION([Prüfungen];[Prüfungen]Sur_LVA=$ LVA) If (Records in selection([Prüfungen])=0) CREATE RECORD([Prüfungen]) [Prüfungen]Matr_Nr:=[Anmeldung_Neu]Matr_Nr [Prüfungen]Sur_LVA:=$LVA [Prüfungen]Note:=0 [Prüfungen]Gruppe:=0 [Prüfungen]Studenten_Name:=[Anmeldung_Neu]Stude nten_Name ACTIVATE LINK([Prüfungen]Matr_Nr) ACTIVATE LINK([Prüfungen]Sur_LVA) SAVE RECORD([Prüfungen]) End if NEXT RECORD End while

III.2.2.2 Das neue Skript btnAnmÜbern Dieses Skript erfüllt eine ganz ähnliche Aufgabe wie obige Prozedur, mit dem kleinen Unterschied daß hier - nachdem der betreffende Button Teil des Layouts

Fallstudie 22

zur Eingabe von Scheinen ist - die interessierende Lehrveranstaltung bereits feststeht. SUCHE([Anmeldung];[Anmeldung]LVA=[LVA]Surrogat;*) SUCHE([Anmeldung]; & [Anmeldung]Aufgenommen=Wahr) Wenn (Datensätze in Auswahl([Anmeldung])>0) Solange (Nicht(Nach der Auswahl([Anmeldung]))) SUCHE([Schein];[Schein]LVA=[LVA]Surrogat;*) SUCHE([Schein]; & [Schein]MatrikelNr=[Anmeldung ]MatrikelNr) Wenn (Datensätze in Auswahl([Schein])=0) ERZEUGE DATENSATZ([Schein]) [Schein]LVA:=[LVA]Surrogat [Schein]MatrikelNr:=[Anmeldung]MatrikelNr SICHERE DATENSATZ([Schein]) ErzgLogEintrag ("Schein gespeichert: LVA-Surr ogat: "+ String([Schein]LVA)+", Matrikel-Nr: "+[Schein ]MatrikelNr+ ", Note: "+String([Schein]NoteGesamt)) eWenn NÄCHSTER DATENSATZ([Anmeldung]) eSolange eWenn

Beim Vergleich der beiden Quellcodes fällt neben den strukturellen Ähnlichkei-ten die unterschiedliche Implementierungssprache auf. Dies ist darauf zurückzu-führen, daß 4th Dimension verschiedene Ländereinstellungen unterstützt und der Sprachstandard von der jeweiligen Installierung abhängt. Ein simples Co-py/Paste war damit allerdings ausgeschlossen. Als problematisch stellten sich auch die zahlreichen Änderungen des Befehls-vorrats, nachdem zwischen den beiden Versionen immerhin zwei Generations-sprünge lagen. Anweisungen der Art SEARCH BY INDEX([Prüfungen]Matr_Nr=[Anmeldung_Neu]M atr_Nr) SEARCH SELECTION([Prüfungen];[Prüfungen]Sur_LVA=$LV A)

waren nunmehr obsolet, nachdem die Suchfunktion etwaige Indizierungen automatisch berücksichtigt. Die Befehlsfolge SUCHE([Schein];[Schein]LVA=[LVA]Surrogat;*) SUCHE([Schein]; & [Schein]MatrikelNr=[Anmeldung]Mat rikelNr)

liefert das gleiche Ergebnis. Zur Umgehung derartiger Schwierigkeiten ist im Programmpaket von 4th Di-mension das Werkzeug 4D Converter enthalten mit dessen Hilfe das Altsystem zunächst auf den Stand der Version 2.0, und danach - mit allen damit verbunde-

Fallstudie 23

nen Problemen - auf Version 3.0 adaptiert hätte werden müssen, um anschlie-ßend unter Verwendung des sogenannten 4D Movers Komponente für Kompo-nente in das neue Informationssystem zu transferieren. Die Unzulänglichkeiten eines derartigen Vorgehens sind offensichtlich, speziell nachdem ohnehin nur die wenigsten Programmbestandteile für eine Wiederverwendung in Frage ka-men. III.2.3 Benutzerschnittstellenanalyse Nach dem Programmstart gelangte der Anwender in die nachfolgend abgebilde-te Benutzeroberfläche.

Abbildung III-1: Die Benutzeroberfläche des alten Informationssystems

Die angebotenen Menues waren nur recht spärlich mit Befehlen ausgestattet, welche wiederum lediglich zu einem Teil auch wirklich Verwendung fanden. Hauptsächlich wurden hier - mittels des Dialogfelds aus Abbildung III-2 - An-meldungen zu Lehrveranstaltungen erfaßt.

Fallstudie 24

Abbildung III-2: Die Erfassung von Anmeldungen

Alle weiteren Menuebefehle führten entweder zu Fehlermeldungen oder liefer-ten vom Benutzer nicht mehr nachvollziehbare Ergebnisse. Aus diesem Grund wurden alle anderen Aktionen - sei es nun die Stammdatenverwaltung oder die Druckausgabe - auf indirektem Wege über den Benutzermodus von 4th Dimen-sion durchgeführt. Dieser Benutzermodus ermöglicht einfache Operationen wie das Anlegen, Än-dern, Löschen, Suchen oder Drucken von Datensätzen unter der Restriktion ei-nes doch erheblich eingeschränkten Bedienungskomforts. Dies soll beispielhaft anhand des Vorgehens zur Erzeugung einer neuen Lehrveranstaltung dargelegt werden werden. Zunächst war die in Betracht kommende Datei - ebenso wie das gewünschte Eingabelayout - aus einer Liste auszuwählen. Anschließend mußte der Menue-befehl zum Anlegen eines neuen Datensatzes aufgerufen werden, worauf fol-gendes Dialogfeld erschien.

Fallstudie 25

Abbildung III-3: Die Verwaltung von Lehrveranstaltungen

Die Attributnamen wurden aus den physischen Dateibeschreibungen übernom-men. Ein eindeutiges Surrogat war selbst zu vergeben, wie die Eingaben für das Semester auszusehen haben wurde an dieser Stelle ebenfalls nicht klar. Mögli-che Lehrveranstaltungsbezeichnungen, -leiter und -typen wurden in Popups an-gezeigt und konnten dort auch modifiziert werden. Andere als die ohnehin von 4th Dimension vorgesehenen Standardfunktionen konnten vom Benutzer nur bei Kenntnis des entsprechenden Prozedurnamens eingesetzt werden.

Abbildung III-4: Die Ausführung von Prozeduren

Nach dem Aufruf der bereits bekannten Prozedur Anmeld->Prüf etwa mußte die gewünschte Lehrveranstaltung erst über deren Surrogat spezifiziert werden

Fallstudie 26

(siehe Abbildung III-5), und das obwohl - wie in Abbildung III-6 - an anderer Stelle sogar eine weit bequemere Auswahlliste implementiert worden war.

Abbildung III-5: Die Auswahl von Lehrveranstaltungen (1)

Abbildung III-6: Die Auswahl von Lehrveranstaltungen (2)

Die Analyse der Benutzerschnittstelle machte die Notwendigkeit einer völligen Überarbeitung deutlich. Die bestehenden Layouts waren fast ausschließlich von 4th Dimension generiert und ohne jede Anpassung übernommen worden, sodaß deren Brauchbarkeit für eine mögliche Wiederverwendung angezweifelt werden mußte.

Fallstudie 27

III.3 Die Spezifikation der Erfassungstransformation Wie obigen Ausführungen zu entnehmen ist, war im Rahmen der Reengineering-Konzeption die Übertragung der vorhandenen Datenbestände von zentralem Interesse. Das logische Datenmodell des Altsystems bildete dabei den Ausgangspunkt der weiteren Vorgehensweise.

Student

LVA

ScheinAnmeldung

schreibttätigt

betrifft betrifft

erhält

Einstiegsklausur

n

1 11

nn

n n

1 1

Abbildung III-7: Das logische Datenmodell des alten Informationssystems

Die Entitäten und Beziehungen des logischen Datenmodells ließen sich relativ einfach aus den physischen Dateibeschreibungen ableiten. III.4 Die Spezifikation der Modelltransformation Um die relevanten Transformationsprozesse zwischen Ausgangs- und Zielmo-dell identifizieren zu können, mußte eine Angleichung des Abstraktionsniveaus der beiden Systembeschreibungen vorgenommen werden.

Fallstudie 28

Diplomprü-fungsergebnis

Diplomprüfung

Einstiegsklau-surergebnis

erreicht betrifft

Student

n

1

nn

erreicht

11

Einstiegsklausur

betrifft

n

1

ScheinAnmeldung

erhältn

1

n

tätigt

1

betrifft

Lehrveran-staltung

n

1

n

betrifft

1

Semesterplan

Lehrveranstal-tungstyp

hat1

n

Termin

hat

1

n

Lehrveranstal-tungsleiter

leitet1nEingangs-

voraussetzung

hat

n

1

hatn

1

1

n

hat

Abbildung III-8: Das logische Datenmodell des neuen Informationssystems

Fallstudie 29

Die korrespondierenden Strukturen konnten dann direkt den logischen Daten-modellen entnommen werden.

Ausgangsmodell Zielmodell

Student

schreibt

Einstiegsklausur

n

1

Einstiegsklau-surergebnis

Student

1

n

erreicht

Einstiegsklausur

betrifft

n

1


1

n

hat

Student

LVA

Anmeldung

tätigt

betrifft

1

n

n

1

Student

Anmeldung

1

n

tätigt

Lehrveran-staltung

1

n

betrifft

1



leitet1n

hatn

1

Student

LVA

Schein

betrifft

erhält

1

n

n

1

Student

Schein

erhältn

1

betrifft

Lehrveran-staltung

n

1



leitet1n

hatn

1

Tabelle III-1: Die relevanten Modelltransformationen

Fallstudie 30

III.5 Die Spezifikation der Realisierungstransformation Zur Umsetzung der ermittelten Modelltransformationen wurde ein eigenes Konvertierungsprogramm implementiert. Diese Maßnahme war angesichts der Komplexität der Transformationsalgorithmen notwendig geworden und hatte außerdem den Vorteil, daß jederzeit - praktisch auf Knopfdruck - die gesamten während der Entwicklung des neuen Informationssystems in der bestehenden Applikation weitergeführten Daten übernommen werden konnten.

Abbildung III-9: Die Benutzeroberfläche des Konvertierungsprogramms

Fallstudie 31

Das Konvertierungsprogramm bildete intern die relevanten Teile der beiden Da-tenmodelle ab. Nach der Importierung der alten Datenbestände wurde der Transformationsprozeß gestartet, der folgende Umformungen beinhaltete: • Erzeugung von Surrogat-Nummern, beispielsweise für Einstiegsklausuren • Zusammenfassung von Attributen, etwa von Vorwahl und lokaler Telefon-

nummer zu einer Nummer • Generierung neuer Attribute, z.B. Erst- und Letztkontakte der Studenten

aus Infomationen gespeicherter Einstiegsklausuren, Anmeldungen und Scheine

• Aufspaltung von Dateien, wie die Trennung von Lehrveranstaltungen, Lehrveranstaltungstypen und Lehrveranstaltungsleitern

Letztgenannte Teiltransformation soll im folgenden Abschnitt beispielhaft er-läutert werden. LVA_Jahr Sur_LVA Ganzzahl LVA_Nr Alpha 10 Sem_Jahr Alpha 4 LVA_Leiter Alpha 40 LVA_Name Alpha 80 LVA_Typ Alpha 2 Stunden Ganzzahl LVA_Name2 Alpha 40

Tabelle III-2: Die alte Datei LVA_Jahr

Die meisten Merkmale der alten Lehrveranstaltungsdatei wurden einer gründli-chen Restrukturierung unterzogen. Das Semesterattribut mußte umgeformt wer-den um eine bessere Verarbeitung zu ermöglichen, daneben wurde der Lehrve-ranstaltungstyp in eine eigene Relation ausgegliedert und erhielt eine neue Be-deutung im Zusammenhang mit den Eingangsvoraussetzungen zu Lehrveran-staltungen.

Fallstudie 32

LVA Surrogat Ganzzahl Nummer Alpha 6 Semester Alpha 5 Typ Alpha 20 Kürzel Alpha 2 Bezeichnung Alpha 40 Leiter Ganzzahl Stunden Ganzzahl MaxTeilnehmer Ganzzahl Kommentar Alpha 30 MarkiertAlt Boolean MarkiertDrk Boolean

Tabelle III-3: Die neue Datei LVA

LVATyp Bezeichnung Alpha 20 LVAKürzel Alpha 2 DPVoraussetzung Boolean EKVoraussetzung Boolean DPTeilnote Boolean

Tabelle III-4: Die neue Datei LVATyp

Als problematisch stellte sich die Behandlung der Lehrveranstaltungsleiterdaten heraus, welche in etwas redundanter Form in einem Attribut der alten Lehrve-ranstaltungsdatei vorlagen. Die Extrahierung dieser Informationen gestaltete sich deshalb so schwierig, weil die Personen teilweise mit vollem Namen und akademischen Titel, teilweise nur mit Nachnamen, etc. abgespeichert worden waren. Das bewußte Attribut mußte daher für jeden Datensatz zerlegt und näher analysiert werden, um letztendlich den tatsächlichen Personenbezug herstellen zu können. Den Lehrveranstaltungsleitern wurden daraufhin eigene Surrogate zugeteilt, über die von nun an die Verknüpfung der beiden Dateien hergestellt werden konnte.

Fallstudie 33

Personal Surrogat Ganzzahl Titel Alpha 30 Vorname Alpha 20 Nachname Alpha 30 Straße Alpha 40 PLZ Alpha 4 Ort Alpha 30 Telefon Alpha 20 UniDurchwahl Ganzzahl Lehrbefugnis Boolean SozialVersNr Alpha 10 Markiert Boolean

Tabelle III-5: Die neue Datei Personal

III.6 Forward-Engineering III.6.1 Entwurf Die weiteren Entwurfsschritte waren durch das logische Datenmodell, welches relativ rasch konkrete Formen angenommen hatte, geprägt. Als ausschlagge-bend dafür zeigte sich nicht zuletzt die starke Datenorientierung von 4th Di-mension selbst, die sich erheblich in der Systemarchitektur widerspiegelt. Die Kenntnis um die besonderen Gegebenheiten und Möglichkeiten der Entwick-lungsumgebung hatte hier - anders als dies möglicherweise bei einer prozedura-len Programmiersprache der Fall gewesen wäre - entscheidenden Einfluß auf etliche noch zu treffende Entwurfsentscheidungen. III.6.1.1 Der Entwurf der Systemarchitektur Eine möglichst problemadäquate Zerlegung des Gesamtsystems in Teilsysteme und Komponenten mußte aus erwähnten Ursachen hochgradig an den zugrunde-liegenden Datenstrukturen angepaßt erfolgen. 4th Dimension unterstützt nur ein äußerst rudimentäres Modularisierungskonzept. Dabei wird zwischen globalen, Datei- und Layoutprozeduren sowie Skripts, welche die Funktionalität hinter einzelnen Benutzerschnittstellenelementen repräsentieren, unterschieden. Layouts und Skripts stehen wiederum in engem Zusammenhang mit bestimmten Dateien. Schon allein daraus wird die Notwendigkeit einer ausgeprägten Daten-orientierung des Architekturentwurfs offenkundig.

Fallstudie 34

III.6.1.2 Der Entwurf der Benutzerschnittstelle Nicht zuletzt aufgrund der diesbezüglichen Schwächen des Altsystems wurde von vornherein auf den Einsatz des integrierten Formulargenerators verzichtet. Stattdessen wurde ein eigenes Benutzerschnittstellenparadigma entworfen, das auch die Zustimmung der zukünftigen Anwender fand. Der dadurch entstandene Mehraufwand konnte durch die Wiederverwendung von Dialogkomponenten einigermaßen in Grenzen gehalten werden. Nähere Informationen zu diesem Thema sind Kapitel IV - Benutzerdokumentation zu entnehmen. III.6.2 Implementierung Die Umsetzung des logischen in das physische Datenmodell erfolgte mit Hilfe des graphischen Entity-Relationship-Editors von 4th Dimension. Dieses Werkzeug ermöglicht die Definition von Objekttypen einschließlich deren Be-ziehungen untereinander ebenso wie die Formulierung verschiedener Integri-tätsbedingungen. Auch nachträgliche Veränderungen an den Datenstrukturen konnten hier relativ problemlos vorgenommen werden. Besonderer Wert wurde auf ein angemessenes Design der Bildschirm- und Drucklayouts gelegt. Der integrierte Screen-Painter offeriert eine mit einem Zeichenprogramm vergleichbare Handhabung der Benutzerschnittstellengestal-tung. Desweiteren kann hier auf vorgefertigte Standard-Transaktionen (wie et-wa das Speichern oder Löschen von Datensätzen über bestimmte Buttons) zu-rückgegriffen werden. Von dieser Möglichkeit wurde jedoch kaum Gebrauch gemacht, da die genannten Manipulationen meist in einem komplexeren Ge-samtzusammenhang standen (beispielsweise aufgrund einer notwendig gewor-denen Aktualisierung der Bildschirmanzeige oder der Erzeugung eines Log-bucheintrags). Die prozedurale Programmiersprache von 4th Dimension beinhaltet mächti-ge Konstrukte, die weit über bloße Zugriffsfunktionen auf die Datenbasis hinausgehen. So konnten auch diffizilere Problemlösungen realisiert werden, wie etwa das automatische Aufnahmeverfahren zu Lehrveranstaltungen. Nach-teilig fiel hingegen die etwas mangelhafte Unterstützung einer strukturierten Programmierweise auf. Aufgrund der geschilderten Leistungsmerkmale der Entwicklungsumgebung erschien eine Strategie des evolutionären Prototypings zweckmäßig. Neben

Fallstudie 35

den erörterten Reengineering-Maßnahmen führte dies zu einer weiteren Vernet-zung von Analyse-, Entwurfs- und Implementierungsarbeiten. III.6.3 Test und Installation Einzelne Komponententests konnten projektbegleitend bereits in den frühen Implementierungsphasen durchgeführt werden. Daß dabei von Beginn an Pra-xisdaten verfügbar waren, ermöglichte die rasche Aufdeckung von Fehlern, die andernfalls erst zu einem späteren Zeitpunkt oder unter realen Einsatzbedin-gungen zutage getreten und dementsprechend schwieriger zu beheben gewesen wären. Auch erste Architekturtests wurden parallel zur Systementwicklung ab-gewickelt. Nach der Installierung einer Vollversion - die aktuellen Datenbestände wurden mittels des Konvertierungsprogramms aus dem Altsystem übernommen - erfolg-te eine Überprüfung des Informationssystems in realer Anwendungsumgebung. Die dabei auftretenden Anpassungserfordernisse waren nur mehr minimal und konnten aufgrund der strikten Trennung von Programm- und Datenstrukturen in 4th Dimension parallel zum Systembetrieb vorgenommen werden.

Benutzerdokumentation 36

IV. Benutzerdokumentation Die vorliegende Benutzerdokumentation soll eine Hilfestellung für den Einsatz des Informationssystems in der Praxis bieten. Sie enthält eine überblicksmäßige Darlegung der potentiellen Einsatzbereiche der Anwendung, eine Auflistung benötigter Ressourcen sowie eine Einführung in die standardmäßige Benutzung des Programms. IV.1 Systembeschreibung IV.1.1 Einsatzbereich Das primäre Anwendungsgebiet des Informationssystems liegt sicherlich im institutsinternen Gebrauch. Rund um den ursprünglichen Zweck, die Verwal-tung von Studentendaten, wird eine Vielzahl von Diensten zur Verfügung ge-stellt, welche sich an dieser Stelle nur querschnittsartig darstellen lassen: • Führung von Studenten-, Lehrveranstaltungs- und Personaldaten • Flexibel konfigurierbares Anmeldewesen mit automatischem Aufnahmever-

fahren • Scheinausstellung, Einstiegsklausur- und Diplomprüfungsverwaltung • Generierung von Semesterplänen • Umfangreiches Angebot an Drucklayouts • Statistische Datenauswertung • Logbuch, Fehlerprotokoll IV.1.2 Benötigte Hard- und Softwareressourcen Für die sinnvollen Nutzung der Applikation sollten zumindest folgende Sy-stemvoraussetzungen gegeben sein: • Macintosh Computer (mit der Leistungsfähigkeit eines eines LCs oder bes-

ser) • 2MB RAM (4MB empfehlenswert) • Betriebssystem-Software 6.0.2 (oder eine neuere Version)


Sollte 4th Dimension (wie angekündigt) in näherer Zukunft für IBM-kompatible PCs verfügbar werden, so steht einem Einsatz auch auf dieser Hardware-Plattform nichts mehr im Wege. Das Informationssystem liegt in Ermangelung eines Compilers zum gegenwär-tigen Zeitpunkt nur in einer Runtime-Fassung vor. Grundvoraussetzung für die Lauffähigkeit ist somit die Bereitstellung von 4th Dimension 3.0.5 (oder einer neueren Version). Desweiteren sollten für eine korrekte Bildschirmdarstellung und Druckausgabe die beiden Zeichensätze • Chicago und • Times New Roman vorhanden sein. Die Gestaltung der Benutzeroberfläche wurde an eine Bildschirmdarstellung von 640•480 Bildpunkten bei 256 Farben ausgerichtet. Bei einer geringerer Auf-lösung bzw. Farbleistung ist u.U. mit kleinen Einschränkungen der Benutzbar-keit zu rechnen. IV.2 Installationsanleitung Zur Programminstallation genügt es, die Datei Fish in ein beliebiges Verzeich-nis auf der Festplatte zu kopieren. Desweiteren wird noch ein gleichnamiges File mit der Extension .data benötigt, welches die Datenbasis enthält. Ist eine derartige Datei nicht vorhanden, so wird sie von 4th Dimension zu Beginn automatisch angelegt und ist dann selbstverständlich leer.


IV.3 Bedienungsanleitung Zweck dieser Bedienungsanleitung ist die Beschreibung der angebotenen Funk-tionalität und des zugrundliegenden Benutzerschnittstellenparadigmas des In-formationssystems. Grundkenntnisse im Umgang mit mausgesteuerten Bedie-nungsumgebungen können vorausgesetzt werden, wie auch auf eine allzu re-dundante Darstellung sich wiederholender Sachverhalte verzichtet werden soll. IV.3.1 Programmstart Nach dem Aufruf der Anwendung erscheint ein Dialogfeld zwecks Identifikati-on des Benutzers.

Abbildung IV-1: Die Benutzeridentifikation

Je nach Zugehörigkeit zu einer bestimmten Benutzergruppe sind die späteren Handlungsmöglichkeiten mehr oder weniger durch die angebotenen Menuebe-fehle vorgegeben. So dürfen etwa Studenten lediglich Anmeldungen zu Lehr-veranstaltungen vornehmen, wohingegen Institutsangehörige oder Mitglieder des Design-Teams den vollen Funktionsumfang nutzen können; für Letztge-nannte stellt sich die Benutzeroberfläche wie in Abbildung IV-2 dar.


Abbildung IV-2: Die Benutzeroberfläche

IV.3.2 Das Menue Ablage Das Menue Ablage enthält Befehle zur Anzeige allgemeiner Programminforma-tionen, zur Einstellung von Systemvariablen, der Führung eines Logbuchs und eines Fehlerprotokolls sowie der Statistikerstellung.


Abbildung IV-3: Das Menue Ablage

IV.3.2.1 Der Befehl Über F.I.S.H... Nach Aufruf dieses Befehls erscheint ein Dialogfeld mit allgemeinen Informa-tionen über Programmversion, Autor, Einsatzbereich, etc. IV.3.2.2 Der Befehl Logbuch Das Informationssystem zeichnet in einem sog. Logbuch laufend die wichtig-sten Datenbanktransaktionen mit und ermöglicht so eine Rekonstruktion des Datenbestandes nach etwaigen Fehlleistungen von Mensch oder Maschine.


Abbildung IV-4: Die Verwaltung des Logbuchs

Nach Auswahl eines Logbucheintrages können über zwei Buttons alle vorheri-gen Aufzeichnungen gelöscht bzw. alle nachfolgenden ausgedruckt werden. IV.3.2.3 Der Befehl Fehlerprotokoll Das Fehlerprotokoll erfüllt eine vergleichbare Funktion wie das Logbuch, nur daß hier sämtliche aufgetretenen Fehler samt Beschreibung der näheren Um-stände abgelegt werden. Diese Beschreibung kann der Benutzer sofort nach Zutagetreten eines Fehlers in einem eigenen Dialogfeld (das auch über mögli-che Ursachen und Hinweise zur Behebung informiert) eingegeben werden. Ähn-lich wie bei der Verwaltung des Logbuchs besteht auch die Gelegenheit, Einträ-ge zu löschen oder auszudrucken.


IV.3.2.4 Der Befehl Systemvariablen Systemvariablen dienen der Festlegung verschiedener Einstellungen an zentra-ler Stelle und ermöglichen damit eine höhere Flexibilität des Gesamtsystems. Tabelle IV-1 veranschaulicht deren Bedeutung. Systemvariable Standard Bedeutung AnmeldungDurchStudent Wahr Soll die Anmeldung durch die Studenten

selbst erfolgen? BenutzernameStudent Student Reservierter Benutzername für die Studenten BesteNote 1 Beste erreichbare Note DetailstatistikBerechnet Falsch Wurde die Detailstatistik schon einmal be-

rechnet? DiagrammTyp 4 Typ des Statistik-Diagramms DiplomprüfungTermin[1] Jänner Bezeichnung des ersten Diplomprüfungster-

mins des Jahres DiplomprüfungTermin[2] März Bezeichnung des zweiten Diplomprüfungs-

termins des Jahres DiplomprüfungTermin[3] Juni Bezeichnung des dritten Diplomprüfungs-

termins des Jahres DiplomprüfungTermin[4] Oktober Bezeichnung des vierten Diplomprüfungs-

termins des Jahres FensterPositionX 4 Horizontale Standard-Position von Fenstern FensterPositionY 42 Vertikale Standard-Position von Fenstern JahreInStatistik 8 Anzahl der Jahre, die in die Statistik einge-

hen sollen MaxNegativeScheine 3 Maximale Anzahl an negativen Scheinen

eines Studenten in einem Lehrveranstaltungs-typ

MinAlternativeAnmeldungen 2 Minimale Anzahl von Prioritäten, die ein Student bei der Anmeldung angeben muß

MinJahreAbwesenheit 3 Anzahl der Jahre, die ein Student abwesend sein muß, um für die Statistik als abgeschlos-sen zu gelten

Rollbalkenbreite 16 Breite des Fenster-Rollbalkens SchlechtesteNote 5 Schlechteste erreichbare Note StandardFensterTyp 8 Typ der Standard-Fenster StartJahr 1985 Erstes Jahr für Diplomprüfungs- und Seme-

sterliste StatistikBerechnet Falsch Wurde die Statistik schon einmal berechnet?

Tabelle IV-1: Die Systemvariablen


Die Systemvariablen können nur von Mitgliedern des Design-Teams verändert werden. IV.3.2.5 Der Befehl Statistik Das Informationssystem bietet umfangreiche statistische Auswertungsmöglich-keiten. Neben einfachen Kennzahlen wie der Anzahl der gespeicherten Studen-ten, Lehrveranstaltungen, Anmeldungen, Scheine, etc. können hier auch komp-lexere Tatbestände - etwa die durchschnittliche Dauer von der ersten Kontakt-aufnahme bis zum Abschluß von Studenten und die Entwicklung der Neuzu-gänge im Zeitablauf - abgelesen werden.

Abbildung IV-5: Die Statistik

Nach Aufruf des Befehls werden zunächst die elementaren und relativ rasch zu berechnenden Werte ermittelt. Der rechte Teil der Statistik bleibt hingegen vo-rerst leer. Durch Klick auf den Button Detail können auch die aufwendigeren Evaluierungen gestartet werden, die je nach Rechnerleistung und Umfang der Daten ein bis mehrere Minuten in Anspruch nehmen können. Dafür sind die Er-


gebnisse dann bei jedem weiteren Aufruf der Statistik sofort verfügbar. Auch eine Druckausgabe ist vorgesehen. IV.3.2.6 Der Befehl Beenden Dieser Befehl beendet die aktuelle Sitzung sofern der Benutzer den Gruppen Design oder Institut angehört. Studenten hingegen können ohne Angabe eines entsprechenden Passworts nicht ohne weiteres aus der Anwendung aussteigen. IV.3.3 Das Menue Bearbeiten Das Menue Bearbeiten wird standardmäßig vom Macintosh-Betriebssystem zur Verfügung gestellt und muß daher an dieser Stelle nicht mehr näher erläutert werden.

Abbildung IV-6: Das Menue Bearbeiten


IV.3.4 Das Menue Institut Unter diesem Punkt sind Befehle zur Verwaltung des Personals und zu Erstel-lung von Semesterplänen zusammengefaßt.

Abbildung IV-7: Das Menue Institut

IV.3.4.1 Der Befehl Personal verwalten Zum Institutspersonal können neben den Lehrveranstaltungsleitern auch Sekre-tärin, Techniker, Tutoren, etc. gezählt werden.


Abbildung IV-8: Die Verwaltung von Institutspersonal

Sind bereits Personal-Datensätze vorhanden, so wird zu Beginn der erste gefun-dene angezeigt, andernfalls gleich ein neuer angelegt. Das Surrogat ist eine ein-deutige Nummer, die intern vergeben wird und danach nicht mehr verändert werden kann. Alle anderen Felder sind frei editierbar; erwähnenswert scheint noch das Optionsfeld Lbf, das darüber Auskunft gibt, ob die Person auch die Befugnis zur Leitung von Lehrveranstaltung hat. Nur dann kann sie eine Lehr-veranstaltung zugeteilt werden (diese Zuordnungen werden darunter in Listen-form angezeigt). Im unteren Teil befinden sich verschiedene Buttons, die in mehr oder weniger variierender Form auch in den meisten anderen Dialogfeldern auftreten und deshalb an dieser Stelle einmal ausführlich erläutert werden sollen.


Suchdialog öffnen

Zum vorherigen Datensatz blättern

Zum ersten Datensatz blättern

Aktuellen Datensatz speichern

Neuen Datensatz anlegen

Zum nächsten Datensatz blättern

Zum letzten Datensatz blättern

Aktuellen Datensatz löschen

Bearbeitung abbrechen

Abbildung IV-9: Die Standard-Buttons

Über den Button Neu wird ein neuer Datensatz erzeugt. Der Button Speichern dient der expliziten Sicherung der getätigten Eingaben - diese erfolgt allerdings auch bei allen anderen Aktionen außer natürlich beim Löschen und beim Ab-brechen der Aktion. Mit Hilfe der kleineren Buttons daneben ist ein beliebiges Blättern zwischen den Datensätzen bzw. zum jeweils ersten und letzten mög-lich. Nicht überall vorgesehen (da nicht immer sinnvoll) wurde der Button Su-chen - er öffnet einen Dialog zur Suche nach Datensätzen anhand verschiedener Kriterien. Durch einen Klick auf Löschen wird der aktuelle Satz unwiderruflich aus der Datenbasis entfernt - allerdings erst nach Bestätigung einer Sicherheits-abfrage. Der Button Abbrechen dient der Beendigung der Bearbeitung ohne Be-rücksichtigung der zuletzt getätigten Änderungen. Eine Statuszeile informiert außerdem laufend über die gerade durchgeführten Transaktionen. IV.3.4.2 Der Befehl Personaldaten drucken Die wichtigsten Stammdaten des Institutspersonals können listenweise ausge-geben werden. Zu diesem Zweck ist es allerdings zunächst notwendig, die ent-sprechenden Personen auszuwählen.


Abbildung IV-10: Die Markierung von Institutspersonal

Dies erfolgt einfach durch Aktivierung eines Optionsfelds neben den jeweiligen Einträgen. Desweiteren erlauben zwei Buttons die Markierung bzw. Demarkie-rung aller angezeigten Datensätze. IV.3.4.3 Der Befehl Semesterplan verwalten Semesterpläne ermöglichen eine übersichtliche Darstellung des Lehrveranstal-tungsangebots des Instituts. Zur Spezifizierung genügt die Auswahl eines Se-mesters, da dazu jeweils nur ein Plan existieren kann.


Abbildung IV-11: Die Verwaltung von Semesterplänen

Gibt es für das angegebene Semester noch keinen Semesterplan, so wird dieser auf Wunsch angelegt, indem vorhandene Lehrveranstaltungen eingetragen und eine Kalenderleiste erzeugt wird. Eine besondere Option ist dabei die Verwen-dung von bereits existierenden Semesterplänen als Vorlage, wodurch umständ-liche Mehrfacheingaben vermieden werden können. Stattdessen werden in den alten Plänen äquivalente Lehrveranstaltungen gesucht und deren Termine und Lerneinheiten einfach an das aktuelle Semester angepaßt. Daraufhin erscheint ein neues Fenster, in dem der so erzeugte Semesterplan nachbearbeitet werden kann.


Abbildung IV-12: Die Bearbeitung von Semesterplänen

Durch Schließen des Fensters wird der Semesterplan automatisch gesichert. IV.3.4.4 Der Befehl Semesterplan drucken Zum Druck eines Semesterplans genügt wiederum die Bestimmung des ge-wünschten Semesters (es werden von vornherein nur diejenigen Semester ange-zeigt, für welche auch wirklich Pläne vorliegen).


IV.3.5 Das Menue Student Hier können Daten über Studenten und Studienrichtungen verwaltet werden.

Abbildung IV-13: Das Menue Student

IV.3.5.1 Der Befehl Studenten verwalten Über diesen Befehl wird die eigentliche Studentenverwaltung aufgerufen.

Abbildung IV-14: Die Verwaltung von Studenten


Die Angabe einer Matrikelnummer ist zwingend, die Studienkennzahl kann über ein Popup aus den vorhandenen Studienrichtungen ausgewählt werden. Die Felder Erstellt und Geändert geben Auskunft darüber, wann der Student zuerst und zuletzt mit dem Institut in Kontakt getreten ist. Die Erfassung des Datums der ersten Diplomprüfung kann von Bedeutung sein, wenn diese eine Eingangs-voraussetzung für bestimmte Lehrveranstaltungen darstellt. Daneben werden die für den Studenten ausgestellten Scheine angezeigt; diese Anzeige hat reinen Informationscharakter und ist nicht editierbar. Anders als beim Institutspersonal, bei dem sich das Datenvolumen in Grenzen hält, kann anhand verschiedener Merkmale nach Studenten gesucht werden.

Abbildung IV-15: Die Suche nach Studenten

Bei den Suchkriterien genügen auch bruchstückhafte Angaben, wobei etwa im gegebenen Beispiel alle Studenten, die 1995 das Studium der Wirtschaftsinfor-matik immatrikuliert haben, gesucht und gefunden werden. Das Suchergebnis wird dann mitsamt der Anzahl der gefundenen Datensätze im Verwaltungsdia-log angezeigt und steht zu einer Weiterverarbeitung zur Verfügung. Klickt man hingegen auf den Button Alle, so gelangen sämtliche vorhandenen Studenten in die Auswahl zurück. IV.3.5.2 Der Befehl Studentendaten drucken Ähnlich wie beim Institutspersonal besteht auch hier die Möglichkeit, bestimm-te Studentendaten auf dem Drucker auszugeben. Abermals müssen zu diesem Zweck die Datensätze, die von Interesse sind, markiert werden.


Abbildung IV-16: Die Markierung von Studenten

Um einen direkten Zugriff auf die Masse an gespeicherten Studenten zu ermög-lichen, kann auch wieder der bereits bekannte Suchdialog aufgerufen werden. Zusätzlich ist auch noch ein Button vorgesehen, über den alle für eine bestimm-te Lehrveranstaltung angemeldeten Studenten angezeigt und dann direkt in die Druckauswahl übernommen werden können. Dazu muß nur die jeweilige Lehr-veranstaltung mit Hilfe eines Popups spezifiziert werden.


Abbildung IV-17: Die Auswahl von Lehrveranstaltungen

Ähnliche Popups treten v.a. im Zusammenhang mit der Verwaltung von An-meldungen und Scheinen desöfteren auf. Sie erlauben eine rasche und komfor-table Bestimmung einer Lehrveranstaltung. Hier werden von vornherein nur diejenigen Lehrveranstaltungen zur Auswahl gestellt, für die Anmeldungen vor-liegen. Für die Druckausgabe stehen zwei verschiedene Layouts zur Verfügung, die aus einer Liste selektiert werden können.


Abbildung IV-18: Die Auswahl von Drucklayouts

IV.3.5.3 Der Befehl Studienrichtungen verwalten Die Führung der verschiedenen Studienrichtungen ist nötig, um den Studenten Studienkennzahlen zuordnen und eine Differenzierung zwischen den Fachrich-tungen Systemplanung und Informationswirtschaft vornehmen zu können.

Abbildung IV-19: Die Verwaltung von Studienrichtungen

Die Verwaltung erfolgt hier ganz ähnlich wie bei beim Institutspersonal oder den Studenten selbst.


IV.3.6 Das Menue Lehrveranstaltung Dieses Menue enthält alle nötigen Funktionen rund um die Lehrveranstaltungs-Stammdatenpflege.

Abbildung IV-20: Das Menue Lehrveranstaltung

IV.3.6.1 Der Befehl LVA verwalten Die Verwaltung der Lehrveranstaltungen ist eine zentrale Aufgabe des Informa-tionssystems, da diese Daten die Basis für die Nutzung der meisten anderen Funktionen darstellen.


Abbildung IV-21: Die Verwaltung von Lehrveranstaltungen

Auch für Lehrveranstaltungen wird ein eindeutiges Surrogat angelegt, da sich die Lehrveranstaltungsnummern über die Jahre hinweg wiederholen können. Wichtig für die weitere Verarbeitung sind auch die Angabe des Semesters und des Lehrveranstaltungstyps, die ebenso wie die verschiedenen Lehrveranstal-tungsleiter über Popups ausgewählt werden können. Will man die automatische Lehrveranstaltungsaufnahmefunktion nutzen, so sollte die Teilnehmerzahl be-schränkt werden. Der Kommentar hilft den Studenten bei der Anmeldung zur Unterscheidung der angebotenen Lehrveranstaltungen. Für jede Lehrveranstaltung können auch ein oder mehrere Termine erzeugt wer-den; zum Anlegen und Löschen einzelner Termineinträge dienen die beiden kleinen Buttons neben der Terminliste. Gleichzeitig erfolgt eine Überprüfung auf mögliche personelle oder räumliche Kollisionen mit anderen Lehrveranstal-tungen. Wird eine derartige Unvereinbarkeit festgestellt, so wird der Benutzer über eine entsprechende Meldung informiert. Die Angabe von Terminen ist auch notwendig, um später adäquate Anwesenheitlisten erstellen zu können.


IV.3.6.2 Der Befehl LVA-Daten drucken Ähnlich wie bei den Studenten- und Personaldaten lassen sich auch Informatio-nen über bestimmte Lehrveranstaltungen listenweise auf dem Drucker ausge-ben. Wiederum müssen diese zuvor markiert werden. IV.3.6.3 Der Befehl Anwesenheitsliste drucken Eine Anwesenheitsliste kann für jede Lehrveranstaltung erstellt werden, der Anmeldungen zugewiesen worden sind. Die Bestimmung der Lehrveranstaltung erfolgt über das an anderer Stelle bereits erläuterte Popup. Die angemeldeten Studenten werden zeilenweise nach Nachnamen sortiert ausgedruckt, in den Spalten stehen die für die Lehrveranstaltung existierenden Termine. IV.3.6.4 Der Befehl LVA-Typen verwalten Lehrveranstaltungstypen dienen der Klassifikation von Lehrveranstaltungen; diese ist notwendig, um angemeldete Studenten auf die Erfüllung der Aufnah-mevoraussetzungen hin überprüfen sowie schriftliche Diplomprüfungsergebnis-se berechnen zu können.


Abbildung IV-22: Die Verwaltung von Lehrveranstaltungstypen

Die Bezeichnung des Lehrveranstaltungstyps muß eindeutig sein; jedem Typ kann ein Kürzel zugeordnet werden (so haben etwa die beiden Typen 1. Übung SP und 2. Übung SP das Kürzel ÜB). Die Aufnahmevoraussetzungen können sich auf eine positive abgeschlossene Einstiegsklausur, die Ablegung der ersten Diplomprüfung oder die Erlangung verschiedener Scheine beziehen. In obigem Beispiel muß der Student für die Aufnahme zu einem Seminar aus SP sowohl den ersten Studienabschluß been-det, als auch zumindest einen der Scheine Übung / Vorlesung SP1 respektive Übung / Vorlesung SP2 abgelegt haben. Wichtig sind hierbei die beiden Opera-toren Und bzw. Oder. Sie geben jeweils Auskunft darüber, ob es sich um ein Mußkriterium handelt, oder ob die Erfüllung einer der Voraussetzungen zur Aufnahme genügt. Desweiteren kann noch per Optionsfeld angegeben werden, ob Lehrveranstaltungen dieses Typs in die Berechnung der schriftlichen Dip-lomprüfungsergebnisse miteinzubeziehen sind.


IV.3.7 Das Menue Anmeldung Dieses Menue stellt Befehle zur Konfiguration des Anmeldungsmodus, zur Er-fassung und Verwaltung von Anmeldungen und zum Druck verschiedener An-meldelisten zu Verfügung.

Abbildung IV-23: Das Menue Anmeldung

IV.3.7.1 Der Befehl Anmeldungsmodus konfigurieren Der Befehl Anmeldungsmodus konfigurieren sollte vor der Erfassung von An-meldung ausgeführt werden. Hier kann angegeben werden, ob die Anmeldung über das Sekretariat oder durch die Studenten selbst erfolgen soll, weiters wel-che Lehrveranstaltungen zur Auswahl stehen und wie viele Prioritäten der Stu-dent dabei mindestens zu vergeben hat. IV.3.7.2 Der Befehl Anmeldungen erfassen Die Erfassung von Anmeldungen über diesen Menuepunkt ist primär für die ei-genständige Durchführung der Anmeldung seitens der Studenten vorgesehen. Wurde zuvor ein derartiger Anmeldungsmodus bestimmt, so erscheint hier zu-nächst eine Aufforderung an den Benutzer, sich als Student zu identifizieren. Danach wird die Menueleiste angepaßt, um einen Zugriff auf andere Befehle als den der Anmeldungserfassung zu verhindern. Genausogut kann die Anmeldung aber auch durch das Institutssekretariat vorgenommen werden - die zur Verfü-gung stehende Funktionalität bleibt dann natürlich unverändert.


Abbildung IV-24: Die Erfassung von Anmeldungen

Zur Bestimmung eines Studenten muß zunächst die Matrikelnummer eingege-ben werden. Ist dieser Student bereits gespeichert, so werden dessen Stammda-ten angezeigt, andernfalls wird ein neuer Datensatz erzeugt. Sollten sich in-zwischen Änderungen etwa bezüglich Adresse oder Telefonnummer ergeben haben, so können diese gleich hier berücksichtigt werden. Die in den Popups angezeigten Lehrveranstaltungen sind genau jene, die zuvor im Rahmen der Konfiguration des Anmeldungsmodus als Anmeldungsalternativen gekenn-zeichnet wurden; bis zu drei Prioritäten können angegeben werden. Desweiteren wird auch noch ein kontextbezogenes Hilfemenue angeboten, falls dem Studen-ten die Handhabung der Anmeldungserfassung nicht ganz klar sein sollte.


IV.3.7.3 Der Befehl Anmeldungen verwalten Die Verwaltung von Anmeldungen bezieht sich im Gegensatz zur obig erläuter-ten Erfassung auf alle möglichen und nicht bloß auf die als Alternativen defi-nierten Lehrveranstaltungen; hier können sowohl abgeschlossene Anmeldevor-gänge nachbearbeitet als auch Neuanmeldungen erfaßt werden.

Abbildung IV-25: Die Verwaltung von Anmeldungen

Die verschiedenen Lehrveranstaltungen können direkt über das bereits bekannte Popup bzw. durch Vor- und Zurückblättern oder eine Suchaktion angesprochen werden. In der Liste finden sich dann alle Anmeldungen wieder, die für die Lehrveranstaltung vorhanden sind. Auch das direkte Hinzufügen und Löschen von Anmeldungen ist möglich. Nach Eingabe einer Matrikelnummer wird der Studentenname sofort angezeigt oder es erfolgt ein Aufruf der Studentenverwal-tung, damit ein entsprechender Datensatz angelegt werden kann. Die beiden Optionsfelder geben für jede Anmeldung Auskunft darüber, ob der Student die Eingangsvoraussetzungen erfüllt und letztendlich in die Lehrveranstaltung auf-


genommen wurde. Diese beiden Sachverhalte lassen sich entweder manuell ein-geben oder per Klick auf den Button Aufnahme automatisch überprüfen. Ist die aktuelle Lehrveranstaltung als Anmeldungsalternative markiert, so wird das Aufnahmeverfahren auch für alle weiteren Alternativen durchlaufen. IV.3.7.4 Der Befehl Anmeldeformular drucken Ein Anmeldeformular beinhaltet nähere Angaben zu einer Lehrveranstaltung und eine Liste, in die sich die Studenten zwecks Anmeldung eintragen können. Zu diesem Zweck ist zuvor die gewünschte Lehrveranstaltung abermals per Po-pup zu spezifizieren. IV.3.7.5 Der Befehl Anmeldeliste drucken Anmeldelisten sind für den internen Gebrauch gedacht. Sie enthalten grundsätz-lich ähnliche Informationen wie sie bei der Verwaltung von Anmeldungen auf dem Bildschirm erscheinen, also alle Anmeldungen samt Matrikelnummer und Name sowie Angaben über die Erfüllung von Eingangsvoraussetzungen und die letztendliche Aufnahme. IV.3.7.6 Der Befehl Aufnahmeliste drucken Aufnahmelisten hingegen können am schwarzen Brett zur Bekanntmachung ausgehängt werden; sie enthalten deshalb keine derart detaillierten Informatio-nen, sondern lediglich die Matrikelnummern jener Studenten, die tatsächlich in die Lehrveranstaltung aufgenommen wurden.


IV.3.8 Das Menue Prüfung Das Menue Prüfung umfaßt Befehle zur Verwaltung von Einstiegsklausuren, Scheinen und Diplomprüfungen sowie zum Druck verschiedener Ergebnislisten.

Abbildung IV-26: Das Menue Prüfung

IV.3.8.1 Der Befehl Einstiegsklausuren verwalten Einstiegsklausuren werden in der Regel einmal pro Semester für bestimmte Lehrveranstaltungstypen durchgeführt. Der positive Abschluß die Vorausset-zung für die Aufnahme zu Lehrveranstaltungen dieses Typs.


Abbildung IV-27: Die Verwaltung von Einstiegsklausuren

Die möglichen Werte für den Lehrveranstaltungstyp und das Semester sind durch Popups vorgegeben. Nach der Eingabe einer Mindestpunktezahl werden sofort jene Studenten bestimmt, welche die Einstiegsklausur positiv abgeschlos-sen haben. Ähnlich wie bei der Verwaltung von Anmeldungen können die ein-zelnen Ergebnisse in einer Liste angelegt und auch wieder gelöscht werden. Das Vorhandensein der Studenten in der Datenbasis wird wie gehabt über deren Matrikelnummer nachgeprüft - sie sind ggf. erst neu anzulegen. IV.3.8.2 Der Befehl Anmeldeformular drucken Anmeldeformulare für Einstiegsklausuren sind grundsätzlich ähnlich aufgebaut wie jene für Lehrveranstaltungen.


IV.3.8.3 Der Befehl Interne Ergebnisliste drucken Interne Ergebnislisten sind für die Ablage am Institut vorgesehen. Sie schließen alle verfügbaren Informationen zu den Einzelresultaten mit ein, so wie sie auch bei der Verwaltung der Einstiegsklausuren auf dem Bildschirm erscheinen. Die auszudruckende Einstiegsklausur kann aus einer Liste selektiert werden. IV.3.8.4 Der Befehl Externe Ergebnisliste drucken Aus Datenschutzgründen weichen die Informationen auf den Aushängen erheb-lichen von jenen der internen Ergebnislisten ab. Externe Ergebnislisten dürfen nur Matrikelnummern und Namen jener Studenten aufweisen, welche die Ein-stiegsklausur positiv abgeschlossen haben. IV.3.8.5 Der Befehl Scheine verwalten Scheine sind ähnlich wie Anmeldungen ein Bindeglied zwischen Lehrveranstal-tungen und Studenten. Durch ihre Führung in der Datenbank können Ergebnis-listen ausgedruckt und der Belegfluß zur Prüfungsabteilung verbessert werden. Außerdem wird dadurch die automatische Aufnahme von Studenten zu Lehr-veranstaltungen und die Berechnung schriftlicher Diplomprüfungsergebnisse erst möglich.


Abbildung IV-28: Die Verwaltung von Scheinen

Die Verwaltung der Scheine funktioniert analog zu jener der Anmeldungen. Die Auswahl einer Lehrveranstaltung erfolgt über ein Popup, die Studenten sind daraufhin listenweise dazu einzugeben. Um unnötigen Erfassungsaufwand zu vermeiden, können über einen Button vorhandene Anmeldungen direkt in die Scheinliste übernommen werden (allerdings nur die jener Studenten, welche auch tatsächlich aufgenommen wurden). Das Prüfungsdatum kann nicht für jede Lehrveranstaltung global festgelegt werden, da - etwa im Falle von Nachklausuren oder externen Seminaren - dies-bezüglich unterschiedliche Werte möglich sind, sondern ist für jeden Eintrag einzeln zu bestimmen. Indes muß ein und dasselbe Datum nicht jedesmal erneut eingegeben werden - es genügt dessen Bestimmung zum Schluß, worauf alle Scheine ohne Datumsangabe auf Wunsch daran angepaßt werden.


Desweiteren erfolgt nach jeder Eingabe eines Scheins die Kontrolle, ob der Stu-dent Lehrveranstaltungen des gleichen Typs nicht schon öfters negativ abge-schlossen hat - ist dies der Fall, so wird darauf entsprechend hingewiesen. IV.3.8.6 Der Befehl Interne Ergebnisliste drucken Zur Spezifikation zusammengehörender Scheine müssen Lehrveranstaltung und Prüfungsdatum per Popup sowie ggf. Fachrichtung (Systemplanung bzw. In-formationswirtschaft) mittels Radio-Button selektiert werden.

Abbildung IV-29: Die Bestimmung von Lehrveranstaltung, Fachrichtung und Prüfungsdatum

Zu einer Lehrveranstaltung kann es mehrere Prüfungstermine geben, wenn eine Nachklausur oder externe Seminararbeiten angeboten wurden. Die Unterschei-dung zwischen Systemplanungs- und Informationswirtschafts-Studenten ist notwendig, wenn der Ausdruck nur für eine der beiden Fachrichtungen erfolgen soll. Ansonsten gilt das im Zusammenhang mit dem Druck interner Einstiegs-klausur-Ergebnislisten Gesagte. IV.3.8.7 Der Befehl Externe Ergebnisliste drucken Dieser Befehl funktioniert äquivalent zu obigem.


IV.3.8.8 Der Befehl Sammelzeugnis drucken Auch hier sind zunächst Lehrveranstaltung und Prüfungsdatum anzugeben. Das Layout der Sammelzeugnisse wurde gemäß den Vorgaben der Prüfungsabtei-lung gestaltet. IV.3.8.9 Der Befehl Diplomprüfungen verwalten Die Verwaltung von Diplomprüfungen ist nicht reiner Selbstzweck. So lassen sich etwa schriftliche Ergebnisse als Notendurchschnitt bestimmter Lehrveran-staltungstypen ermitteln. Abgespeicherte Diplomprüfungsergebnisse sind außerdem eine wichtige Berechnungsbasis für die Statistikerstellung.

Abbildung IV-30: Die Verwaltung von Diplomprüfungen


Die Diplomprüfungstermine müssen nicht extra angelegt werden, da automa-tisch eine entsprechende Terminliste angeboten werden kann. Die Bezeichnung der einzelnen Termine läßt sich einfach über die Systemvariablen abändern. Die Ergebnisse werden wie gewohnt erzeugt und auch wieder entfernt. Die Festlegung der schriftlichen, mündlichen und Gesamtnoten kann für jeden Ein-trag gesondert oder durch einen vom Informationssystem selbst erstellten Vor-schlag erfolgen. Dieser Vorschlag wird für das schriftliche Ergebnis als Mittel-wert der miteinzubeziehenden Scheine (welche das sind wird über die Lehrve-ranstaltungstypen festgelegt) ermittelt. Das Gesamtresultat setzt sich dagegen einfach zu gleichen Teilen aus schriftlicher und mündlicher Teilnote zusammen. IV.3.8.10 Der Befehl Informationsliste drucken Informationslisten liefern eine Aufstellung über alle zu einem bestimmten Dip-lomprüfungstermin angemeldeten Studenten, eine Auflistung der von ihnen ab-gelegten Lehrveranstaltungen sowie einen eventuell erstellten Vorschlag für die schriftliche Note. IV.3.8.11 Der Befehl Ergebnisliste drucken Nach abgeschlossener Diplomprüfung können die einzelnen Ergebnisse in einer Liste zusammenfassend ausgedruckt werden.

Systemdokumentation 71

V. Systemdokumentation Die Systemdokumentation hat eine Schlüsselrolle in Hinblick auf das Verständ-nis des internen Aufbaus des Informationssystems. Sie bildet die Grundlage für zukünftige Wartungs- und Weiterentwicklungsvorhaben und soll diesem Tatbe-stand durch ein entsprechendes Maß an Detailliertheit Rechnung tragen, ohne daß dabei der Überblick über die Gesamtzusammenhänge verloren geht. 4th Dimension sieht eine Klassifikation der Systemkomponenten in • (Daten-) Struktur • Layouts • Prozeduren • Menues • Kennwörter • Auswahllisten und • Prozesse vor. Aus Gründen der Vereinheitlichung wurde diese Gliederung auch in die Systemdokumentation übernommen. Die eingehende Erörterung jeder einzelnen Komponente würde allerdings nicht nur den Rahmen dieser Arbeit sprengen, sondern wäre durch die Berücksichtigung teilweise trivialer Algorithmen gleichsam unzweckmäßig in Hinblick auf Anwendbarkeit und Akzeptanz der Dokumentation. Infolgedessen wurde der Schwerpunkt der ausführlicheren Er-läuterungen auf komplexe und wartungsintensive Teilbereiche gelegt.


V.1 Struktur V.1.1 Übersicht

EinstklsrErgeb

Student

LVA

ScheinAnmeldung LVATyp

LVAKürzel

LVA-Vorausstzng

Personal LVAPlan

Einstklsr

Semesterplan

Zeittafel

Semester

Fehler

FehlerprotokollStudienrichtungDiplomprüfung

DiplprfgErgeb

Logbuch

Termin

DummySystemVar

Kontrolle beim Löschen: Keine Kontrolle Lösche verknüpfte Datensätze Nicht löschen, wenn verknüpfte Datensätze vorhanden

Abbildung V-1: Das physische Datenmodell


V.1.2 Die Datei Anmeldung Anmeldung LVA Ganzzahl Indiziert; Eingabe zwingend; Eingebbar; Änderbar MatrikelNr Alpha 7 Indiziert; Eingabe zwingend; Eingebbar; Änderbar Priorität Ganzzahl Eingebbar; Änderbar VorstzgErfüllt Boolean Eingebbar; Änderbar Aufgenommen Boolean Eingebbar; Änderbar

Tabelle V-1: Die Datei Anmeldung

V.1.3 Die Datei Diplomprüfung Diplomprüfung Termin Alpha 20 Indiziert; Einmalig; Eingabe zwingend; Eingebbar

Tabelle V-2: Die Datei Diplomprüfung

V.1.4 Die Datei DiplprfgErgeb DiplprfgErgeb Termin Alpha 20 Indiziert; Eingabe zwingend; Eingebbar; Änderbar Datum Datum Indiziert; Eingabe zwingend; Eingebbar; Änderbar Zeit Uhrzeit Indiziert; Eingebbar; Änderbar MatrikelNr Alpha 7 Indiziert; Eingabe zwingend; Eingebbar; Änderbar NoteSchriftlich Ganzzahl Eingebbar; Änderbar NoteMündlich Ganzzahl Eingebbar; Änderbar NoteGesamt Ganzzahl Eingebbar; Änderbar

Tabelle V-3: Die Datei DiplprfgErgeb

V.1.5 Die Datei Dummy Dummy

Tabelle V-4: Die Datei Dummy


V.1.6 Die Datei Einstklsr Einstklsr Surrogat Ganzzahl Indiziert; Einmalig; Eingabe zwingend LVATyp Alpha 20 Indiziert; Eingabe zwingend; Eingebbar; Änderbar Semester Alpha 5 Indiziert; Eingabe zwingend; Eingebbar; Änderbar MinPunkte Ganzzahl Eingebbar; Änderbar

Tabelle V-5: Die Datei Einstklsr

V.1.7 Die Datei EinstklsrErgeb EinstklsrErgeb Einstklsr Ganzzahl Indiziert; Eingabe zwingend; Eingebbar; Änderbar MatrikelNr Alpha 7 Indiziert; Eingabe zwingend; Eingebbar; Änderbar Punkte Ganzzahl Eingebbar; Änderbar Aufgenommen Boolean Eingebbar; Änderbar Kommentar Text Eingebbar; Änderbar

Tabelle V-6: Die Datei EinstklsrErgeb

V.1.8 Die Datei Fehler Fehler Code Ganzzahl Indiziert; Einmalig; Eingabe zwingend; Eingebbar Beschreibung Text Eingebbar; Änderbar Behebung Text Eingebbar; Änderbar

Tabelle V-7: Die Datei Fehler

V.1.9 Die Datei Fehlerprotokoll Fehlerprotokoll Fehler Ganzzahl Indiziert; Eingabe zwingend; Eingebbar; Änderbar Datum Datum Eingebbar; Änderbar Zeit Uhrzeit Eingebbar; Änderbar Protokoll Text Eingebbar; Änderbar

Tabelle V-8: Die Datei Fehlerprotokoll


V.1.10 Die Datei Logbuch Logbuch Datum Datum Indiziert; Eingebbar; Änderbar Zeit Uhrzeit Indiziert; Eingebbar; Änderbar Transaktion Alpha 80 Eingebbar; Änderbar

Tabelle V-9: Die Datei Logbuch

V.1.11 Die Datei LVA LVA Surrogat Ganzzahl Indiziert; Einmalig; Eingabe zwingend Nummer Alpha 6 Indiziert; Eingabe zwingend; Eingebbar; Änderbar Semester Alpha 5 Indiziert; Eingebbar; Änderbar Typ Alpha 20 Indiziert; Eingebbar; Änderbar Kürzel Alpha 2 Indiziert; Eingebbar; Änderbar Bezeichnung Alpha 40 Indiziert; Eingabe zwingend; Eingebbar; Änderbar Leiter Ganzzahl Indiziert; Eingebbar; Änderbar Stunden Ganzzahl Indiziert; Eingebbar; Änderbar MaxTeilnehmer Ganzzahl Eingebbar; Änderbar Kommentar Alpha 30 Eingebbar; Änderbar MarkiertAlt Boolean Indiziert; Eingebbar; Änderbar MarkiertDrk Boolean Indiziert; Eingebbar; Änderbar

Tabelle V-10: Die Datei LVA

V.1.12 Die Datei LVAKürzel LVAKürzel Bezeichnung Alpha 2 Indiziert; Einmalig; Eingabe zwingend; Eingebbar

Tabelle V-11: Die Datei LVAKürzel


V.1.13 Die Datei LVAPlan LVAPlan Semester Alpha 5 Indiziert; Eingabe zwingend; Eingebbar; Änderbar LVA Ganzzahl Indiziert; Eingebbar; Änderbar Beschriftung Text Eingebbar; Änderbar StoffWoche1 Text Eingebbar; Änderbar StoffWoche2 Text Eingebbar; Änderbar StoffWoche3 Text Eingebbar; Änderbar StoffWoche4 Text Eingebbar; Änderbar StoffWoche5 Text Eingebbar; Änderbar StoffWoche6 Text Eingebbar; Änderbar StoffWoche7 Text Eingebbar; Änderbar StoffWoche8 Text Eingebbar; Änderbar StoffWoche9 Text Eingebbar; Änderbar StoffWoche10 Text Eingebbar; Änderbar StoffWoche11 Text Eingebbar; Änderbar StoffWoche12 Text Eingebbar; Änderbar StoffWoche13 Text Eingebbar; Änderbar StoffWoche14 Text Eingebbar; Änderbar StoffWoche15 Text Eingebbar; Änderbar

Tabelle V-12: Die Datei LVAPlan

V.1.14 Die Datei LVATyp LVATyp Bezeichnung Alpha 20 Indiziert; Einmalig; Eingabe zwingend; Eingebbar LVAKürzel Alpha 2 Indiziert; Eingebbar; Änderbar DPVoraussetzung Boolean Eingebbar; Änderbar EKVoraussetzung Boolean Eingebbar; Änderbar DPTeilnote Boolean Eingebbar; Änderbar

Tabelle V-13: Die Datei LVATyp


V.1.15 Die Datei LVAVoraussetzng Termin LVATyp Alpha 20 Indiziert; Eingabe zwingend; Eingebbar; Änderbar Operator Boolean Indiziert; Eingabe zwingend; Eingebbar; Änderbar LVATypVorstzg Uhrzeit Eingebbar; Änderbar Ende Uhrzeit Eingebbar; Änderbar Ort Alpha 20 Eingebbar; Änderbar Kommentar Text Eingebbar; Änderbar

Tabelle V-14: Die Datei LVAVoraussetzng

V.1.16 Die Datei Personal Personal Surrogat Ganzzahl Indiziert; Einmalig; Eingabe zwingend Titel Alpha 30 Eingebbar; Änderbar Vorname Alpha 20 Eingebbar; Änderbar Nachname Alpha 30 Indiziert; Eingebbar; Änderbar Straße Alpha 40 Eingebbar; Änderbar PLZ Alpha 4 Eingebbar; Änderbar Ort Alpha 30 Eingebbar; Änderbar Telefon Alpha 20 Eingebbar; Änderbar UniDurchwahl Ganzzahl Eingebbar; Änderbar Lehrbefugnis Boolean Indiziert; Eingebbar; Änderbar SozialVersNr Alpha 10 Eingebbar; Änderbar Markiert Boolean Indiziert; Eingebbar; Änderbar

Tabelle V-15: Die Datei Personal

V.1.17 Die Datei Schein Schein LVA Ganzzahl Indiziert; Eingabe zwingend; Eingebbar; Änderbar MatrikelNr Alpha 7 Indiziert; Eingabe zwingend; Eingebbar; Änderbar Prüfungsdatum Datum Indiziert; Eingebbar; Änderbar NoteÜbungsklsr Ganzzahl Eingebbar; Änderbar NoteGesamt Ganzzahl Eingebbar; Änderbar Kommentar Text Eingebbar; Änderbar

Tabelle V-16: Die Datei Schein


V.1.18 Die Datei Semester Semester Bezeichnung Alpha 5 Indiziert; Einmalig; Eingabe zwingend

Tabelle V-17: Die Datei Semester

V.1.19 Die Datei Semesterplan Semesterplan Semester Alpha 5 Indiziert; Einmalig; Eingabe zwingend; Eingebbar; Änder-

bar SemesterLang Alpha 30 Eingebbar; Änderbar Kommentar Text Eingebbar; Änderbar Anmeldung Text Eingebbar; Änderbar Legende Text Eingebbar; Änderbar

Tabelle V-18: Die Datei Semesterplan

V.1.20 Die Datei Student Student MatrikelNr Alpha 7 Indiziert; Einmalig; Eingabe zwingend; Eingebbar; Änder-

bar Kennzahl Alpha 3 Indiziert; Eingebbar; Änderbar Vorname Alpha 20 Indiziert; Eingebbar; Änderbar Nachname Alpha 30 Indiziert; Eingebbar; Änderbar Straße Alpha 40 Eingebbar; Änderbar PLZ Alpha 4 Eingebbar; Änderbar Ort Alpha 30 Eingebbar; Änderbar Telefon Alpha 20 Eingebbar; Änderbar Diplomprüfung Datum Eingebbar; Änderbar ErstelltDatum Datum Indiziert; Eingebbar; Änderbar GeändertDatum Datum Indiziert; Eingebbar; Änderbar Markiert Boolean Indiziert; Eingebbar; Änderbar

Tabelle V-19: Die Datei Student


V.1.21 Die Datei Studienrichtung Studienrichtung Kennzahl Alpha 3 Indiziert; Einmalig; Eingabe zwingend; Eingebbar Bezeichnung Alpha 30 Eingebbar; Änderbar Fachrichtung Boolean Indiziert; Eingebbar; Änderbar

Tabelle V-20: Die Datei Studienrichtung

V.1.22 Die Datei SystemVar SystemVar Bezeichner Alpha 30 Indiziert; Einmalig; Eingabe zwingend; Eingebbar; Änder-

bar Typ Alpha 20 Eingabe zwingend; Eingebbar; Änderbar Wert Alpha 20 Eingebbar; Änderbar Kommentar Text Eingebbar; Änderbar

Tabelle V-21: Die Datei SystemVar

V.1.23 Die Datei Termin Termin LVA Ganzzahl Indiziert; Eingabe zwingend; Eingebbar; Änderbar Datum Datum Indiziert; Eingabe zwingend; Eingebbar; Änderbar Beginn Uhrzeit Eingebbar; Änderbar Ende Uhrzeit Eingebbar; Änderbar Ort Alpha 20 Eingebbar; Änderbar Kommentar Text Eingebbar; Änderbar

Tabelle V-22: Die Datei Termin


V.1.24 Die Datei Zeittafel Zeittafel Semester Alpha 5 Indiziert; Einmalig; Eingabe zwingend; Eingebbar; Änder-

bar BeginnWoche1 Datum Eingebbar; Änderbar BeginnWoche2 Datum Eingebbar; Änderbar BeginnWoche3 Datum Eingebbar; Änderbar BeginnWoche4 Datum Eingebbar; Änderbar BeginnWoche5 Datum Eingebbar; Änderbar BeginnWoche6 Datum Eingebbar; Änderbar BeginnWoche7 Datum Eingebbar; Änderbar BeginnWoche8 Datum Eingebbar; Änderbar BeginnWoche9 Datum Eingebbar; Änderbar BeginnWoche10 Datum Eingebbar; Änderbar BeginnWoche11 Datum Eingebbar; Änderbar BeginnWoche12 Datum Eingebbar; Änderbar BeginnWoche13 Datum Eingebbar; Änderbar BeginnWoche14 Datum Eingebbar; Änderbar BeginnWoche15 Datum Eingebbar; Änderbar

Tabelle V-23: Die Datei Zeittafel


V.2 Layouts V.2.1 Übersicht Datei Layout Bedeutung Anmeldung Ausgabe Standard-Ausgabelayout Eingabe Standard-Eingabelayout EingebdAnmldDrk Eingebundenes Layout zum Druck von An-

meldelisten EingebdAnwesDrk Eingebundenes Layout zum Druck von An-

wesenheitslisten EingebdAufnDrk Eingebundenes Layout zum Druck von Auf-

nahmelisten EingebdLVA Eingebundenes Layout zum Verwaltung von

Anmeldungen Erfassung Erfassung von Anmeldungen Diplomprüfung Ausgabe Standard-Ausgabelayout Druck Druck von Diplomprüfungsergebnissen Eingabe Verwaltung von Diplomprüfungen Spezifizierung Bestimmung von Diplomprüfungen DiplprfgErgeb Ausgabe Standard-Ausgabelayout Eingabe Standard-Eingabelayout EingebdDiplprfg Eingabe von Diplomprüfungsergebnissen EingebdDPDrk Eingebundenes Layout zum Druck von Dip-

lomprüfungsergebnissen InformatLstDrk Druck von Diplomprüfungs-

Informationslisten Dummy Aktion Aktionsbestätigung Auswahl Auswahl aus einer Liste Dummy Eingabe Eingabe eines Wertes Fehlerprotokoll Verwaltung des Fehlerprotokolls Frage Beantwortung einer Frage Hilfe Anzeige einer Hilfemeldung Information Anzeige einer Informationsmeldung Logbuch Verwaltung des Logbuchs MarkLVADruck Markierung von Lehrveranstaltungen als

Druckauswahl MarkLVAAlt Markierung von Lehrveranstaltungen als

Anmeldungsalternativen MarkPersonal Markierung von Institutsangehörigen als

Druckauswahl MarkStudent Markierung von Studenten als Druckauswahl Statistik Erstellung einer Statistik StatistikDrk Druck einer Statistik


Datei Layout Bedeutung SystemVar Verwaltung von Systemvariablen ÜberFISH Anzeige der Programminformation Einstklsr AnmeldeFrmDrk Druck von Anmeldeformularen Ausgabe Standard-Ausgabelayout Eingabe Verwaltung von Einstiegsklausuren ExternDrk Druck von externen Einstiegsklausurergeb-

nissen InternDrk Druck von internen Einstiegsklausurergeb-

nissen Spezifizierung Bestimmung von Einstiegsklausuren Suche Suche nach Einstiegsklausuren EinstklsrErgeb Ausgabe Standard-Ausgabelayout Eingabe Standard-Eingabelayout EingebdEinstkls Eingebundenes Layout zur Verwaltung von

Einstiegsklausurergebnissen EingebdEKExtDrk Eingebundenes Layout zum Druck von ex-

ternen Einstiegsklausurergebnislisten EingebdEKIntDrk Eingebundenes Layout zum Druck von inter-

nen Einstiegsklausurergebnislisten Fehler Ausgabe Standard-Ausgabelayout Eingabe Standard-Eingabelayout Fehlerprotokoll Ausgabe Standard-Ausgabelayout Druck Druck des Fehlerprotokolls Eingabe Protokollierung eines aufgetretenen Fehlers EingebdDummy Eingebundenes Layout zur Verwaltung des

Fehlerprotokolls Logbuch Ausgabe Standard-Ausgabelayout Druck Druck des Logbuchs Eingabe Standard-Eingabelayout EingebdDummy Eingebundenes Layout zur Verwaltung des

Logbuchs LVA AnmeldeFrmDrk Druck von Anmeldeformularen AnmeldeLstDrk Druck von Anmeldelisten Anmeldung Verwaltung von Anmeldungen AnwesenhLstDrk Druck von Anwesenheitslisten AufnahmeLstDrk Druck von Aufnahmelisten Ausgabe Standard-Ausgabelayout Druck Druck von Lehrveranstaltungen Eingabe Verwaltung von Lehrveranstaltungen EingebdMarkAlt Eingebundenes Layout zur Markierung von

Lehrveranstaltungen als Anmeldungsalterna-tiven

EingebdMarkDrk Eingebundenes Layout zur Markierung von Lehrveranstaltungen als Druckauswahl


Datei Layout Bedeutung EingebdPersonal Eingebundenes Layout zur Anzeige von

Lehrveranstaltungen von Institutsangehörigen ErgebnlstExtDrk Druck von externen Lehrveranstaltungser-

gebnislisten ErgebnlstIntDrk Druck von internen Lehrveranstaltungser-

gebnislisten SammelzgnDrk Druck von Sammelzeugnissen Schein Verwaltung von Scheinen Spezifizierung Bestimmung von Lehrveranstaltungen Suche Suche nach Lehrveranstaltungen LVAKürzel Ausgabe Standard-Ausgabelayout Eingabe Standard-Eingabelayout LVAPlan Ausgabe Standard-Ausgabelayout Eingabe Standard-Eingabelayout EingebdSemPl Eingebundenes Layout zur Eingabe von Se-

mesterplänen EingebdSemPlDrk Eingebundenes Layout zum Druck von Se-

mesterplänen LVATyp Ausgabe Standard-Ausgabelayout Eingabe Verwaltung von Lehrveranstaltungstypen LVAVoraussetzng Ausgabe Standard-Ausgabelayout Eingabe Standard-Eingabelayout EingebdLVATyp Eingebundens Layout zur Verwaltung von

Lehrveranstaltungstypen Personal Ausgabe Standard-Eingabelayout Druck Druck von Institutsangehörigen Eingabe Verwaltung von Institutsangehörigen EingebdDummy Eingebundenes Layout zur Markierung von

Institutsangehörigen als Druckauswahl Schein Ausgabe Standard-Ausgabelayout Eingabe Standard-Eingabelayout EingebdERExtDrk Eingebundenes Layout zum Druck von ex-

ternen Lehrveranstaltungsergebnislisten EingebdERIntDrk Eingebundenes Layout zum Druck von inter-

nen Lehrveranstaltungsergebnislisten EingebdInLstDrk Eingebundenes Layout zum Druck von

Scheinen von Studenten EingebdLVA Eingebundenes Layout zur Verwaltung von

Scheinen EingebdStudent Eingebundenes Layout zur Anzeige von

Scheinen von Studenten EingebdSZgDrk Eingebundenes Layout zum Druck von

Sammelzeugnissen Spezifizierung Bestimmung von Scheinen


Datei Layout Bedeutung Semester Ausgabe Standard-Ausgabelayout Eingabe Standard-Eingabelayout Semesterplan Ausgabe Standard-Ausgabelayout Druck Druck von Semesterplänen Eingabe Eingabe von Semsterplänen Spezifizierung Verwaltung von Semesterplänen SpezifizierungD Bestimmung von Semesterplänen zum Druck Student Ausgabe Standard-Ausgabelayout Eingabe Verwaltung von Studenten EingebdMark Eingebundenes Layout zur Markierung von

Studenten als Druckauswahl InformatLstDrk Druck von Studenteninformationslisten StammdatenDrk Druck von Studentenstammdaten Suche Suche nach Studenten Studienrichtung Ausgabe Standard-Ausgabelayout Eingabe Verwaltung von Studienrichtungen SystemVar Ausgabe Standard-Ausgabelayout Eingabe Standard-Eingabelayout EingebdDummy Eingebundenes Layout zur Verwaltung von

Systemvariablen Termin Ausgabe Standard-Ausgabelayout Eingabe Standard-Eingabelayout EingebdLVA Eingebundenes Layout zur Verwaltung von

Terminen von Lehrveranstaltungen Zeittafel Ausgabe Standard-Ausgabelayout Eingabe Standard-Eingabelayout EingebdSemPl Eingebundenes Layout zur Eingabe von Zeit-

tafeln von Semesterplänen EingebdSemPlDrk Eingebundenes Layout zum Druck von Zeit-

tafeln von Semesterplänen

Tabelle V-24: Layouts (Übersicht)

V.2.2 Das Layout Anmeldung-Erfassung V.2.2.1 Das Skript btnSpeicher Bei der Erfassung von Anmeldungen werden zunächst eventuell geänderte Stu-denten-Stammdaten gespeichert und ein entsprechender Logbucheintrag er-zeugt. Wenn (vMatrikelNr#"")

Systemdokumentation 85 Wenn (Datensatz geändert([Student])) ErzgLogEintrag ("Student gespeichert: Matrikel- Nr: "+ [Student]MatrikelNr+", Kennzahl: "+[Student]Ken nzahl+ ", Name: "+[Student]Nachname+" "+[Student]Vorna me) vStatus:="Student gespeichert" eWenn [Student]GeändertDatum:=Aktuelles Datum SICHERE DATENSATZ([Student])

Danach wird überprüft, ob der Student auch genügend Prioritäten vergeben hat. Dies läßt sich über die Werte der drei Popups vPriorität1, vPriorität2 und vPriorität3 feststellen, die dann größer als 0 sind, wenn eine Selektion erfolgt ist. Hat sich der Student bereits einmal für die angebotenen Lehrveranstaltungen angemeldet, so müssen die alten Anmeldungen zuvor noch gelöscht werden. Wenn ((IntFkt (vPriorität1)+IntFkt (vPriorität2)+ IntFkt (vPriorität3)>=SystemVar ("MinAlternativeA nmeldungen")) SUCHE([LVA];[LVA]MarkiertAlt=Wahr) AUSWAHL ÜBERTRAGEN([Anmeldung]LVA) SUCHE IN AUSWAHL([Anmeldung];[Anmeldung]Matrike lNr=vMatrikelNr) Wenn (Datensätze in Auswahl([Anmeldung])>0) Solange (Nicht(Nach der Auswahl([Anmeldung])) ) ErzgLogEintrag ("Anmeldung gelöscht: LVA-Su rrogat: "+ String([Anmeldung]LVA)+", Matrikel-Nr: "+[A nmeldung]MatrikelNr+ ", Priorität: "+String([Anmeldung]Priorität )) NÄCHSTER DATENSATZ([Anmeldung]) eSolange LÖSCHE AUSWAHL([Anmeldung]) eWenn

Schließlich werden die neuen Anmeldungen abgespeichert. Wenn (vPriorität1>0) ERZEUGE DATENSATZ([Anmeldung]) [Anmeldung]LVA:=vSurrogat{vPriorität1} [Anmeldung]MatrikelNr:=vMatrikelNr [Anmeldung]Priorität:=1 [Anmeldung]VorstzgErfüllt:=Falsch SICHERE DATENSATZ([Anmeldung]) ErzgLogEintrag ("Anmeldung gespeichert: LVA-S urrogat: "+ String([Anmeldung]LVA)+", Matrikel-Nr: "+[Anm eldung]MatrikelNr+ ", Priorität: "+String([Anmeldung]Priorität)) eWenn Wenn (vPriorität2>0) ERZEUGE DATENSATZ([Anmeldung]) [Anmeldung]LVA:=vSurrogat{vPriorität2} [Anmeldung]MatrikelNr:=vMatrikelNr [Anmeldung]Priorität:=2 [Anmeldung]VorstzgErfüllt:=Falsch SICHERE DATENSATZ([Anmeldung]) ErzgLogEintrag ("Anmeldung gespeichert: LVA-S urrogat: "+ String([Anmeldung]LVA)+", Matrikel-Nr: "+[Anm eldung]MatrikelNr+ ", Priorität: "+String([Anmeldung]Priorität)) eWenn Wenn (vPriorität3>0) ERZEUGE DATENSATZ([Anmeldung]) [Anmeldung]LVA:=vSurrogat{vPriorität3}

Systemdokumentation 86 [Anmeldung]MatrikelNr:=vMatrikelNr [Anmeldung]Priorität:=3 [Anmeldung]VorstzgErfüllt:=Falsch SICHERE DATENSATZ([Anmeldung]) ErzgLogEintrag ("Anmeldung gespeichert: LVA-S urrogat: "+ String([Anmeldung]LVA)+", Matrikel-Nr: "+[Anm eldung]MatrikelNr+ ", Priorität: "+String([Anmeldung]Priorität)) eWenn AktLayErfAnmldg vStatus:="Anmeldung gespeichert" Sonst Information ("Speicherung nicht möglich";"Die S peicherung ist nicht möglich, da nicht zumindest "+ String(SystemVar ("MinAlternativeAnmeldungen")) + " Prioritäten vergeben wurden.") eWenn Sonst Information ("Speicherung nicht möglich";"Die Spe icherung ist nicht möglich, da keine Matrikel-Nr angegeben wurde.") eWenn

V.2.3 Das Layout Diplomprüfung-Eingabe V.2.3.1 Das Skript btnVrschlgS Zur Erstellung eines Notenvorschlags für die schriftliche Diplomprüfung müs-sen anfangs jene Lehrveranstaltungstypen gesucht werden, welche in die Be-rechnung miteinzubeziehen sind. C_GANZZAHL($zähler;$summe) C_BOOLEAN($erfüllt) Wenn (Datensätze in Auswahl([DiplprfgErgeb])>0) Wenn (FrageBestätigt ("Vorschlag erstellen";"Woll en Sie die Vorschlagserstellung für die schriftlichen Noten wirklich "+ "durchführen? (Etwaige manuell eingegebene schrif tliche Ergebnisse gehen dabei "+"verloren)") TEMPORÄRE AUSWAHL KOPIEREN([DiplprfgErgeb];"Dip lprfgErgeb") SUCHE([LVATyp];[LVATyp]DPTeilnote=Wahr) EINDEUTIGE WERTE([LVATyp]Bezeichnung;vLVATyp)

Für jeden Studenten ist im einzelnen zu prüfen, ob er die benötigten Scheine positiv abgeschlossen hat. Durch eine aufsteigende Sortierung kommt für jeden Lehrveranstaltungstyp nur das jeweils beste Ergebnis in die Wertung, sofern mehrere Scheine vorhanden sind. Die Noten werden zusammengezählt und zum Schluß durch die Anzahl der Lehrveranstaltungen dividiert. ERSTER DATENSATZ([DiplprfgErgeb]) Solange (Nicht(Nach der Auswahl([DiplprfgErgeb] ))) $erfüllt:=Wahr $zähler:=0 $summe:=0 Solange (($zähler<Tabellengröße(vLVATyp)) & ( $erfüllt))

Systemdokumentation 87 $zähler:=$zähler+1 SUCHE([Schein];[Schein]MatrikelNr=[Diplprfg Ergeb]MatrikelNr;*) SUCHE([Schein]; & [Schein]NoteGesamt>=Syste mVar ("BesteNote");*) SUCHE([Schein]; & [Schein]NoteGesamt< SystemVar ("SchlechtesteNote");*) SUCHE([Schein]; & [LVA]Typ=vLVATyp{$zähler} ) SORTIERE AUSWAHL([Schein];[Schein]NoteGesam t;>) $erfüllt:=(Datensätze in Auswahl([Schein])> 0) $summe:=$summe+[Schein]NoteGesamt eSolange Wenn (($erfüllt) & ($zähler>0)) [DiplprfgErgeb]NoteSchriftlich:=Runde($summ e/$zähler;0) Sonst [DiplprfgErgeb]NoteSchriftlich:=SystemVar ( "BesteNote")-1 eWenn SICHERE DATENSATZ([DiplprfgErgeb]) NÄCHSTER DATENSATZ([DiplprfgErgeb]) eSolange TEMPORÄRE AUSWAHL BENUTZEN("DiplprfgErgeb") TEMPORÄRE AUSWAHL LÖSCHEN("DiplprfgErgeb") vStatus:="Vorschläge für schriftliche Noten ers tellt" eWenn Sonst Information ("Keine Anmeldungen";"Es wurden noch keine Anmeldungen für diesen Diplomprüfungstermin eingegeben, "+"sodaß auch keine Vorschlagserstellung erfolgen kann.") eWenn

V.2.4 Das Layout Dummy-Statistik V.2.4.1 Das Skript btnDetail Zu Beginn der Berechnung der Detailstatistik werden alle Studenten eruiert, die entweder eine Diplomprüfung abgelegt haben oder seit einigen Jahren nicht mehr in Kontakt mit dem Institut getreten sind. Diese Studenten gelten als abge-schlossen; wieviel Zeit das durchschnittlich in Anspruch genommen hat kann als Differenz zwischen [Student]ErstelltDatum und [Student]GeändertDatum ermittelt werden. C_GANZZAHL($zähler) C_DATUM($jahrBeginn;$jahrEnde) Wenn (Nicht(SystemVar ("DetailstatistikBerechnet")) ) SUCHE MIT FORMEL([Student]; ([Student]GeändertDatum#[Student]ErstelltDatum) & (Jahr von(Aktuelles Datum)-Jahr von([Student]Geän dertDatum)>= SystemVar ("MinJahreAbwesenheit")) | (HatDiplprfg ([Student]MatrikelNr))) vAbgStudent:=Datensätze in Auswahl([Student]) vAktStudent:=vAnzStudent-vAbgStudent vMitDlfz:=0 Wenn (Datensätze in Auswahl([Student])>0) Solange (Nicht(Nach der Auswahl([Student]))) vMitDlfz:=vMitDlfz+([Student]GeändertDatum-[S tudent]ErstelltDatum) NÄCHSTER DATENSATZ([Student]) eSolange vMitDlfz:=vMitDlfz/365/Datensätze in Auswahl([S tudent])*2 eWenn


Im Diagramm werden die Entwicklungen der Neuzugänge an Studenten sowie der Anzahl der angebotenen Lehrveranstaltungen und der ausgestellten Scheine im Zeitablauf abgebildet. Die einzelnen Werte müssen also für jedes Jahr be-rechnet und in einer Tabelle abgelegt werden. TABELLE GANZZAHL(vDgrJahr;SystemVar ("JahreInStat istik")) TABELLE GANZZAHL(vDgrStudent;SystemVar ("JahreInS tatistik")) TABELLE GANZZAHL(vDgrLVA;SystemVar ("JahreInStati stik")) TABELLE GANZZAHL(vDgrSchein;SystemVar ("JahreInSt atistik")) Für ($zähler;1;SystemVar ("JahreInStatistik")) vDgrJahr{$zähler}:=Jahr von(Aktuelles Datum)- SystemVar ("JahreInStatistik")+$zähler $jahrBeginn:=Datum("1.1."+String(vDgrJahr{$zähl er})) $jahrEnde:=Datum("31.12."+String(vDgrJahr{$zähl er})) SUCHE([Student];[Student]ErstelltDatum>=$jahrBe ginn;*) SUCHE([Student]; & [Student]ErstelltDatum<=$jah rEnde) vDgrStudent{$zähler}:=Datensätze in Auswahl([St udent]) SUCHE MIT FORMEL([LVA]; SemesterJahr ([LVA]Semester)=Mod(vDgrJahr{$zähl er};100)) vDgrLVA{$zähler}:=Datensätze in Auswahl([LVA]) AUSWAHL ÜBERTRAGEN([Schein]LVA) vDgrSchein{$zähler}:=Datensätze in Auswahl([Sch ein]) eFür DIAGRAMM(vDiagramm; SystemVar ("DiagrammTyp");vDgrJahr;vDgrStudent;vD grLVA;vDgrSchein) DIAGRAMM PARAMETER(vDiagramm; vDgrJahr{1};vDgrJahr{SystemVar ("JahreInStatistik ")};0;0;Wahr;Wahr;Wahr; "Neuzugänge";"LVAs";"Scheine")

V.2.5 Das Layout LVA-Anmeldung V.2.5.1 Das Skript btnAufnahme Hinter diesem Button steht das automatische Aufnahmeverfahren. Vorerst wird überprüft, ob die aktuelle Lehrveranstaltung als Anmeldungsalternative mar-kiert wurde; ist dies der Fall, so muß das Verfahren auch für die anderen Alter-nativen abgewickelt werden. Die zu untersuchenden Anmeldungen wandern in die aktuelle Auswahl und werden nach Priorität aufsteigend sortiert. C_GANZZAHL($lvaSurrogat;$maxTeiln;$aufgTeiln) C_BOOLEAN($erfüllt;$Mußvorstzg) Wenn (Datensätze in Auswahl([Anmeldung])>0) Wenn (FrageBestätigt ("Automatische Aufnahme";"Wo llen Sie die automatische Aufnahme wirklich durchführen? (Etwa ige manuell "+ "eingegebene Daten über Aufnahmevoraussetzungen o der die Aufnahme selbst gehen "+"dabei verloren)") Wenn ([LVA]MarkiertAlt) SUCHE([LVA];[LVA]MarkiertAlt=Wahr)

Systemdokumentation 89 AUSWAHL ÜBERTRAGEN([Anmeldung]LVA) Sonst EINEN DATENSATZ AUSWÄHLEN([LVA]) eWenn AUF AUSWAHL ANWENDEN([Anmeldung];[Anmeldung]Auf genommen:=Falsch) AUF AUSWAHL ANWENDEN([Anmeldung];[Anmeldung]Vor stzgErfüllt:=Falsch) SORTIERE AUSWAHL([Anmeldung];[Anmeldung]Priorit ät;>)

Für jede Anmeldung werden Student, Lehrveranstaltung und Lehrveranstal-tungstyp gesucht. Anhand des Typs können auch die Eingangsvoraussetzungen festgestellt werden. Solange (Nicht(Nach der Auswahl([Anmeldung]))) SUCHE([Student];[Student]MatrikelNr=[Anmeldun g]MatrikelNr) SUCHE([LVA];[LVA]Surrogat=[Anmeldung]LVA) $maxTeiln:=[LVA]MaxTeilnehmer TEMPORÄRE AUSWAHL KOPIEREN([Anmeldung];"Anmel dung") SUCHE IN AUSWAHL([Anmeldung];[Anmeldung]LVA=[ LVA]Surrogat;*) SUCHE IN AUSWAHL([Anmeldung]; & [Anmeldung]Au fgenommen=Wahr) $aufgTeiln:=Datensätze in Auswahl([Anmeldung] ) TEMPORÄRE AUSWAHL BENUTZEN("Anmeldung") TEMPORÄRE AUSWAHL LÖSCHEN("Anmeldung") SUCHE([LVATyp];[LVATyp]Bezeichnung=[LVA]Typ) Wenn (Datensätze in Auswahl([LVATyp])>0) SUCHE([LVAVoraussetzng];[LVAVoraussetzng]LV ATyp=[LVA]Typ) Wenn ((Datensätze in Auswahl([LVAVoraussetz ng])>0) | ([LVATyp]DPVoraussetzung) | ([LVATyp]EKVora ussetzung))

Ist die Ablegung bestimmter Lehrveranstaltungen notwendig für die Aufnahme, so werden zuerst alle positiven Scheine des Studenten gesucht und davon auf die zugehörigen Lehrveranstaltungstypen rückgeschlossen. Wenn (Datensätze in Auswahl([LVAVorausset zng])>0) SUCHE([Schein];[Schein]MatrikelNr=[Anme ldung]MatrikelNr;*) SUCHE([Schein]; & [Schein]NoteGesamt>= SystemVar ("BesteNote");*) SUCHE([Schein]; & [Schein]NoteGesamt< SystemVar ("SchlechtesteNote")) VERKNÜPFE([Schein];[LVA]) AUSWAHL ZU TABELLE([LVA]Typ;vScheinTyp)

Die erforderlichen Lehrveranstaltungen müssen iterativ mit den gefundenen Scheinen abgeglichen werden. Dabei ist immer zu beachten, ob es sich um eine zwingende Voraussetzung handelt oder nicht. Auskunft darüber gibt das Attri-but [LVAVoraussetzng]Operator. Der Variable $erfüllt kann entommen wer-den, ob den Bedingungen bis dato entsprochen wurde.

Systemdokumentation 90 ERSTER DATENSATZ([LVAVoraussetzng]) $erfüllt:=Falsch Wiederhole $Mußvorstzg:=[LVAVoraussetzng]Operato r Wenn ($Mußvorstzg) $erfüllt:=(Suche in Tabelle(vSchein Typ; [LVAVoraussetzng]LVATypVorstzg)#-1) Sonst $erfüllt:=(($erfüllt) | (Suche in T abelle(vScheinTyp; [LVAVoraussetzng]LVATypVorstzg)#-1) ) eWenn NÄCHSTER DATENSATZ([LVAVoraussetzng]) Bis (((Nicht($erfüllt)) & ($Mußvorstzg) ) | (Nach der Auswahl([LVAVoraussetzng])))

Eine etwaige Kontrolle auf Abschluß des ersten Studienabschnitts erfolgt über das Merkmal [Student]Diplomprüfung. $erfüllt:=(($erfüllt) & (([Student]Dipl omprüfung#!00.00.00!) | (Nicht([LVATyp]DPVoraussetzung))))) Sonst $erfüllt:=(([Student]Diplomprüfung#!00. 00.00!) | (Nicht([LVATyp]DPVoraussetzung))) eWenn

Schließlich kann auch noch eine Einstiegsklausur eine Aufnahmebedingung darstellen. Diese muß dem gleichen Lehrveranstaltungstyp zugeordnet sein wie die Lehrveranstaltung selbst. Wenn ([LVATyp]EKVoraussetzung) LADE VERKNÜPFUNG([Anmeldung]) SUCHE([Einstklsr];[Einstklsr]LVATyp=[LV ATyp]Bezeichnung) AUSWAHL ÜBERTRAGEN([EinstklsrErgeb]Eins tklsr) SUCHE IN AUSWAHL([EinstklsrErgeb]; [EinstklsrErgeb]MatrikelNr=[Anmeldung]M atrikelNr;*) SUCHE IN AUSWAHL([EinstklsrErgeb]; [EinstklsrErgeb]Aufgenommen=Wahr) $erfüllt:=($erfüllt & (Datensätze in Auswahl([EinstklsrErgeb] )>0)) eWenn

An dieser Stelle steht fest, ob der Student die Anforderungen erfüllt. Ob er hin-gegen auch wirklich aufgenommen wird, hängt von den verbleibenden Rest-plätzen ab, die als Differenz der maximalen Teilnehmerzahl und der bisher auf-genommen Studenten berechnet werden. [Anmeldung]VorstzgErfüllt:=$erfüllt Sonst [Anmeldung]VorstzgErfüllt:=Wahr eWenn

Systemdokumentation 91 SICHERE DATENSATZ([Anmeldung]) Wenn (($aufgTeiln<$maxTeiln) & ([Anmeldung] VorstzgErfüllt)) TEMPORÄRE AUSWAHL KOPIEREN([Anmeldung];"A nmeldung") SUCHE IN AUSWAHL([Anmeldung]; [Anmeldung]MatrikelNr=[Student]MatrikelNr ;*) SUCHE IN AUSWAHL([Anmeldung]; & [Anmeldun g]Aufgenommen=Wahr) Wenn (Datensätze in Auswahl([Anmeldung])= 0) TEMPORÄRE AUSWAHL BENUTZEN("Anmeldung") [Anmeldung]Aufgenommen:=Wahr Sonst TEMPORÄRE AUSWAHL BENUTZEN("Anmeldung") eWenn TEMPORÄRE AUSWAHL LÖSCHEN("Anmeldung") eWenn eWenn eWenn SICHERE DATENSATZ([Anmeldung]) NÄCHSTER DATENSATZ([Anmeldung]) eSolange SUCHE([LVA];[LVA]Surrogat=vSurrogat{vLVA}) eWenn Sonst Information ("Keine Anmeldungen";"Es wurden noch keine Anmeldungen für diese Lehrveranstaltungen eingegeben, "+"sodaß au ch keine Aufnahme erfolgen kann.") eWenn

V.2.6 Das Layout Schein-EingebdLVA V.2.6.1 Das Skript NoteGesamt Nach jeder Eingabe einer Note wird abgefragt, ob der Student die Lehrveran-staltung nicht schon zu oft negativ abgeschlossen hat. Dazu ist es zunächst er-forderlich, alle Scheine von Lehrveranstaltungen des gleichen Typs ausfindig zu machen. C_GANZZAHL($lvaSurrogat) C_ALPHA(20;$lvaTyp) C_ALPHA(7;$matrikelNr) [Schein]NoteGesamt:=Maximum ([Schein]NoteGesamt;Sys temVar ("BesteNote")-1) [Schein]NoteGesamt:=Minimum ([Schein]NoteGesamt;Sys temVar ("SchlechtesteNote")) $lvaTyp:=[LVA]Typ $matrikelNr:=[Schein]MatrikelNr SICHERE DATENSATZ([Schein]) TEMPORÄRE AUSWAHL AUSSCHNEIDEN([LVA];"LVA") TEMPORÄRE AUSWAHL AUSSCHNEIDEN([Schein];"Schein") SUCHE([LVA];[LVA]Typ=$lvaTyp) AUSWAHL ÜBERTRAGEN([Schein]LVA)


Innerhalb dieser Auswahl wird dann nach negativen Scheinen des aktuellen Studenten gesucht. SUCHE IN AUSWAHL([Schein];[Schein]MatrikelNr=$matri kelNr;*) SUCHE IN AUSWAHL([Schein]; & [Schein]NoteGesamt=Sys temVar ("SchlechtesteNote")) Wenn (Datensätze in Auswahl([Schein])>=SystemVar (" MaxNegativeScheine")) Information ("Mehrmals negativ";"Der Student "+[S tudent]MatrikelNr+ " "+[Student]Nachname+" "+[Student]Vorname+Zeiche n(13)+ "hat die Lehrveranstaltung "+$lvaTyp+" bereits "+ String(Datensätze in Auswahl([Schein]))+"-mal neg ativ abgeschlossen.") eWenn TEMPORÄRE AUSWAHL BENUTZEN("Schein") TEMPORÄRE AUSWAHL BENUTZEN("LVA") TEMPORÄRE AUSWAHL LÖSCHEN("Schein") TEMPORÄRE AUSWAHL LÖSCHEN("LVA")

V.2.6.2 Das Skript Prüfungsdatum Über dieses Skript erfolgt auf Wunsch die Anpassung der Datumsangaben. C_DATUM($datum) Wenn ((Alt([Schein]Prüfungsdatum)=!00.00.00!) & (Datensätze in Auswahl([Schein])>1)) Wenn (FrageBestätigt ("Datumsaktualisierung";"Sol len alle anderen Scheine der Lehrveranstaltung "+[LVA]Bezeichnung+" ohne D atumsangabe auf den "+ String([Schein]Prüfungsdatum)+" aktualisiert werd en?")) $datum:=[Schein]Prüfungsdatum TEMPORÄRE AUSWAHL KOPIEREN([Schein];"Schein") SUCHE IN AUSWAHL([Schein];[Schein]Prüfungsdatum =!00.00.00!) AUF AUSWAHL ANWENDEN([Schein];[Schein]Prüfungsd atum:=$datum) TEMPORÄRE AUSWAHL BENUTZEN("Schein") TEMPORÄRE AUSWAHL LÖSCHEN("Schein") eWenn eWenn

V.2.7 Das Layout Semesterplan-Spezifizierung V.2.7.1 Das Skript btnEdit Durch Klick auf den Button btnEdit werden nicht nur vorhandene Semesterplä-ne zur Bearbeitung aufgerufen, sondern auch neue angelegt. Wünscht der Be-nutzer die Verwendung einer Vorlage, so muß zunächst nach einem passenden alten Semesterplan gesucht werden, der dupliziert wird. Andernfalls werden die Attribute mit fixen Standardwerten belegt.

Systemdokumentation 93 C_ALPHA(20;$lvaTyp) C_GANZZAHL($lvaLeiter;$zähler) C_BOOLEAN($vorlage) SUCHE([Semesterplan];[Semesterplan]Semester=vSemest er{vSemester}) Wenn (Datensätze in Auswahl([Semesterplan])=0) Wenn (FrageBestätigt ("Neuer Semesterplan";"Für d ieses Semester gibt es noch keinen Plan. Wollen Sie einen neuen erzeugen ?")) SUCHE([Semesterplan];[Semesterplan]Semester= SemesterTyp (vSemester{vSemester})+"@") Wenn (Datensätze in Auswahl([Semesterplan])>0) $vorlage:=FrageBestätigt ("Semesterplanvorlag e";"Wollen Sie einen alten Semesterplan als Vorlage verwenden?") Sonst $vorlage:=Falsch eWenn Wenn ($vorlage) LETZTER DATENSATZ([Semesterplan]) DUPLIZIERE DATENSATZ([Semesterplan]) Sonst ERZEUGE DATENSATZ([Semesterplan]) Wenn (SemesterTyp (vSemester{vSemester})="WS" ) [Semesterplan]Kommentar:="Abkürzungen gemäß :"+Zeichen(13)+ "Heinrich, L. J.: SYSTEMPLANUNG I, 6. Aufla ge, Oldenbourg Verlag 1994 bzw."+Zeichen(13)+"Heinrich, L. J.: IN FORMATIONSMANAGEMENT, 4. Auflage, Oldenbourg Verlag 1992" Sonst [Semesterplan]Kommentar:="Abkürzungen gemäß :"+Zeichen(13)+ "Heinrich, L. J.: SYSTEMPLANUNG II, 5. Aufl age, Oldenbourg Verlag 1994" eWenn [Semesterplan]Anmeldung:="Anmeldung:"+Zeichen (13)+"Vom 00.00. - 00.00.0000 am Institutssekretariat für Übunge n und Seminare."+ Zeichen(13)+"Für die Seminaranmeldung sind da s 1. Diplomprüfungszeugnis und ein "+Zeichen(13)+" Vorlesungsschein Systemplanung mitzubringen."+Zeichen(13)+Zeic hen(13)+"Anmeldung PROST:"+Zeichen(13)+"Vom 00.00. - 00.00.0000 Kopfgebäude 3. Stock (Dr. P. Reisch)" [Semesterplan]Legende:="Legende:"+Zeichen(13) +"SP ....... Systemplanung"+Zeichen(13)+"IM ...... Informationsmanagement"+Zeichen(13)+" • .... ... für Nicht-Wirtschaftsinformatiker"+Zeichen(13 )+" * ....... für Berufstätige" eWenn [Semesterplan]Semester:=vSemester{vSemester} Wenn (SemesterTyp ([Semesterplan]Semester)="WS" ) [Semesterplan]SemesterLang:="Wintersemester " + String(SemesterJahr ([Semesterplan]Semester)) +"/"+ String(Mod(SemesterJahr ([Semesterplan]Semest er)+1;100))) Sonst [Semesterplan]SemesterLang:="Sommersemester " + String(SemesterJahr ([Semesterplan]Semester)) eWenn SICHERE DATENSATZ([Semesterplan]) vStatus:="Neuer Semesterplan angelegt" eWenn eWenn

Auch die Zeittafel läßt sich aus einem vorhandenen Plan erzeugen. Jedes Datum wird um den zeitlichen Abstand der beiden Semesterpläne erhöht und auf einen Montag zurückgerechnet.


Wenn (Datensätze in Auswahl([Semesterplan])>0) SUCHE([Zeittafel];[Zeittafel]Semester=[Semesterpl an]Semester) Wenn (Datensätze in Auswahl([Zeittafel])=0) SUCHE([Zeittafel];[Zeittafel]Semester= SemesterTyp ([Semesterplan]Semester)+"@") Wenn (($vorlage) & (Datensätze in Auswahl([Zeit tafel])>0)) LETZTER DATENSATZ([Zeittafel]) DUPLIZIERE DATENSATZ([Zeittafel]) Für ($zähler;1;15) Feld(Datei(»[Zeittafel]);$zähler+1))»:= Wochenanfang (Feld(Datei(»[Zeittafel]);$zäh ler+1)»+ (366*(SemesterJahr ([Semesterplan]Semester) - SemesterJahr ([Zeittafel]Semester)))) eFür Sonst ERZEUGE DATENSATZ([Zeittafel]) Wenn (Teilstring([Semesterplan]Semester;1;2)= "WS") Für ($zähler;1;15) Feld(Datei(»[Zeittafel]);$zähler+1)»:= Wochenanfang (Datum("1.10."+ String(SemesterJahr ([Semesterplan]Semest er)))+($zähler*7)) eFür Sonst Für ($zähler;1;15) Feld(Datei(»[Zeittafel]);$zähler+1)»:= Wochenanfang (Datum("1.3."+ String(SemesterJahr ([Semesterplan]Semest er)))+($zähler*7)) eFür eWenn eWenn [Zeittafel]Semester:=[Semesterplan]Semester SICHERE DATENSATZ([Zeittafel]) eWenn

Zu allen Lehrveranstaltungen des aktuellen Semesters werden in alten Seme-sterplänen äquivalente Einträge gesucht. Ist die Suche erfolgreich, so können die dort angegebenen Lerneinheiten übernommen werden. Die Beschriftung im Semesterplan setzt aus aus den Stammdaten der Lehrveranstaltung sowie den zugeordneten Terminen, Räumen und Lehrveranstaltungsleitern zusammen. SUCHE([LVA];[LVA]Semester=[Semesterplan]Semester) Wenn (Datensätze in Auswahl([LVA])>0) Solange (Nicht(Nach der Auswahl([LVA]))) SUCHE([LVAPlan];[LVAPlan]Semester=[LVA]Semest er;*) SUCHE([LVAPlan]; & [LVAPlan]LVA=[LVA]Surrogat ) Wenn (Datensätze in Auswahl([LVAPlan])=0) Wenn ($vorlage) $lvaTyp:=[LVA]Typ $lvaLeiter:=[LVA]Leiter TEMPORÄRE AUSWAHL KOPIEREN([LVA];"vLVA") SUCHE([LVA];[LVA]Semester= SemesterTyp ([Semesterplan]Semester)+"@"; *) SUCHE([LVA]; & [LVA]Typ=$lvaTyp;*) SUCHE([LVA]; & [LVA]Leiter=$lvaLeiter) AUSWAHL ÜBERTRAGEN([LVAPlan]LVA) TEMPORÄRE AUSWAHL BENUTZEN("vLVA")

Systemdokumentation 95 eWenn Wenn (Datensätze in Auswahl([LVAPlan])>0) ERSTER DATENSATZ([LVAPlan]) DUPLIZIERE DATENSATZ([LVAPlan]) Sonst ERZEUGE DATENSATZ([LVAPlan]) eWenn [LVAPlan]Semester:=[LVA]Semester [LVAPlan]LVA:=[LVA]Surrogat [LVAPlan]Beschriftung:=String(Num([LVA]Numm er);"###.###")+ " "+[LVA]Typ LADE VERKNÜPFUNG([LVA]Leiter) Wenn (Datensätze in Auswahl([Personal])>0) [LVAPlan]Beschriftung:=[LVAPlan]Beschrift ung+Zeichen(13)+"("+ [Personal]Nachname+")" eWenn SUCHE([Termin];[Termin]LVA=[LVA]Surrogat) Wenn (Datensätze in Auswahl([Termin])>0) [LVAPlan]Beschriftung:=[LVAPlan]Beschrift ung+Zeichen(13)+ Wochentag ([Termin]Datum)+" "+String([Ter min]Beginn;2)+" - "+ String([Termin]Ende;2)+" Uhr,"+Zeichen(13 )+[Termin]Ort eWenn LADE VERKNÜPFUNG([LVA]Typ) Wenn ([LVATyp]DPVoraussetzung) [LVAPlan]Voraussetzung:="1. Studienabschn itt abgeschlossen"+Zeichen(13) Sonst [LVAPlan]Voraussetzung:="" eWenn Wenn ([LVATyp]EKVoraussetzung) [LVAPlan]Voraussetzung:=[LVAPlan]Vorausse tzung+ "Positive Einstiegsklausur"+Zeichen(13) eWenn SUCHE([LVAVoraussetzng];[LVAVoraussetzng]LV ATyp=[LVA]Typ) Wenn (Datensätze in Auswahl([LVAVoraussetzn g])>0) [LVAPlan]Voraussetzung:=[LVAPlan]Vorausse tzung+ [LVAVoraussetzng]LVATypVorstzg+Zeichen(13 ) NÄCHSTER DATENSATZ([LVAVoraussetzng]) Solange (Nicht(Nach der Auswahl([LVAVorau ssetzng]))) Wenn ([LVAVoraussetzng]Operator) [LVAPlan]Voraussetzung:=[LVAPlan]Vora ussetzung+ "und "+[LVAVoraussetzng]LVATypVorstzg +Zeichen(13) Sonst [LVAPlan]Voraussetzung:=[LVAPlan]Vora ussetzung+ "oder "+[LVAVoraussetzng]LVATypVorstz g+Zeichen(13) eWenn NÄCHSTER DATENSATZ([LVAVoraussetzng]) eSolange eWenn SICHERE DATENSATZ([LVAPlan]) eWenn NÄCHSTER DATENSATZ([LVA]) eSolange eWenn ÖffneFenster (765;815;SystemVar ("StandardFenster Typ");"Semesterplan editieren";"SichereSemPlan") ÄNDERE DATENSATZ([Semesterplan]) eWenn


V.2.8 Das Layout Student-Eingabe Die im folgenden Abschnitt behandelten Skripts sind jene der Standard-Buttons, wie sie in den vielen Dialogfeldern vorkommen. Dementsprechend gleichen sich - mit Ausnahme der Datei, auf die sich die Transaktionen beziehen - auch die darin enthaltenen Anweisungen. V.2.8.1 Das Skript btnAbbreche ABBRECHEN

V.2.8.2 Das Skript btnErster SichereStudent ERSTER DATENSATZ([Student]) vStatus:="Erster Student"

V.2.8.3 Das Skript btnLetzter SichereStudent LETZTER DATENSATZ([Student]) vStatus:="Letzter Student"

V.2.8.4 Das Skript btnLöschen Wenn (FrageBestätigt ("Student löschen";"Wollen Sie diesen Studenten wirklich löschen? (Möglicherweise existieren "+"Sch eine oder Anmeldungen von ihm/ihr)")) SICHERE DATENSATZ([Student]) ErzgLogEintrag ("Student gelöscht: Matrikel-Nr:"+ [Student]MatrikelNr+ ", Kennzahl:"+[Student]Kennzahl+", Name: "+[Stude nt]Nachname+ " "+[Student]Vorname)"" LÖSCHE DATENSATZ([Student]) vStatus:="Student gelöscht" ALLE DATENSÄTZE([Student]) SORTIERE AUSWAHL([Student];[Student]MatrikelNr;>) Sonst vStatus:="Löschvorgang abgebrochen" eWenn

V.2.8.5 Das Skript btnNächster Wenn (Nicht(Nach der Auswahl([Student]))) SichereStudent NÄCHSTER DATENSATZ([Student]) vStatus:="Nächster Student" Sonst

Systemdokumentation 97 vStatus:="Kein nächster Student" eWenn

V.2.8.6 Das Skript btnNeu SichereStudent ERZEUGE DATENSATZ([Student]) vStatus:="Neuer Student angelegt"

V.2.8.7 Das Skript btnSpeicher SichereStudent

V.2.8.8 Das Skript btnSuchen SichereStudent SucheStudent

V.2.8.9 Das Skript btnVorherig Wenn (Nicht(Vor der Auswahl([Student]))) SichereStudent VORHERIGER DATENSATZ([Student]) vStatus:="Vorheriger Student" Sonst vStatus:="Kein vorheriger Student" eWenn

V.2.8.10 Das Skript vKennzahl Am Beispiel dieses Popups zur Auswahl einer Studienkennzahl wird deutlich, wie verhindert werden kann, daß nach einem Mausklick ohne Selektion der alte Wert verlorengeht. Wenn (vKennzahl#0) [Student]Kennzahl:=vKennzahl{vKennzahl} Sonst vKennzahl:=Suche in Tabelle(vKennzahl;[Student]Ke nnzahl) eWenn


V.2.9 Das Layout Student-Suche V.2.9.1 Das Skript btnSuchen Dieser Button startet die Suche nach Datensätzen, auf die bestimmte Kriterien zutreffen, wobei auch unvollständige Eingaben richtig interpretiert werden müssen. Hier ist das Joker-Zeichen "@" hilfreich, welches jedoch nur in Ver-bindung mit Zeichenketten verwendet werden kann. Auch mit aus diesem Grund sind [Student]MatrikelNr und [Student]Kennzahl vom Typ Alpha. SUCHE([Student];[Student]MatrikelNr=vMatrikelNr+"@" ;*) SUCHE([Student]; & [Student]Kennzahl=vKennzahl{vKen nzahl}+"@";*) SUCHE([Student]; & [Student]Vorname=vVorname+"@";*) SUCHE([Student]; & [Student]Nachname=vNachname+"@") Im Falle : (Datensätze in Auswahl([Student])=0) ALLE DATENSÄTZE([Student]) vStatus:="Keine Studenten gefunden" : (Datensätze in Auswahl([Student])=1) vStatus:="1 Student gefunden" Sonst vStatus:=String(Datensätze in Auswahl([Student] ))+" Studenten gefunden" eIm Falle SORTIERE AUSWAHL([Student];[Student]MatrikelNr;>) ABBRECHEN


V.3 Prozeduren V.3.1 Globale Prozeduren V.3.1.1 Übersicht Prozedur Bedeutung AktionBestätigt Öffnet ein Dialogfeld zur Bestätigung einer Aktion AktLayErfAnmldg Aktualisiert die Anzeigen des Layouts Anmeldung-Erfassung AktLayVwlAnmldg Aktualisiert die Anzeigen des Layouts Anmeldung-Eingabe AktLayVwlEinstk Aktualisiert die Anzeigen des Layouts Einstklsr-Eingabe AktLayZeittafel Aktualisiert die Anzeigen des Layouts Zeittafel-EingebdSemPl(Drk) Auswahl Öffnet ein Dialogfeld zum Treffen einer Auswahl Beende Beendet die Session BrichAb Bricht die aktuelle Aktion ab DiplprfgSpzfzrt Öffnet ein Dialogfeld zur Bestimmung eines Diplomprüfungstermins DruckeAnmldFrm Druckt ein Anmeldeformular für eine Lehrveranstaltung DruckeAnmldLst Druckt eine Anmeldeliste für eine Lehrveranstaltung DruckeAnwesLst Druckt ein Anwesenheitsliste für eine Lehrveranstaltung DruckeAufnLst Druckt eine Aufnahmeliste für eine Lehrveranstaltung DruckeDPErgbLst Druckt eine Ergebnisliste eines Diplomprüfungstermins DruckeDPInfoLst Druckt eine Informationsliste bzgl. eines Diplomprüfungstermins DruckeEinstkExt Druckt eine externe Ergebnisliste einer Einstiegsklausur DruckeEinstkFrm Druckt ein Anmeldeformular für eine Einstiegsklausur DruckeEinstkInt Druckt eine interne Ergebnisliste einer Einstiegsklausur DruckeErgebnExt Druckt eine externe Ergebnisliste einer Lehrveranstaltung DruckeErgebnInt Druckt eine interne Ergebnisliste einer Lehrveranstaltung DruckeLVA Druckt eine Informationsliste bzgl. bestimmter Lehrveranstaltungen DruckePersonal Druckt eine Informationsliste bzgl. bestimmter Institutsangehöriger DruckeSammelzgn Druckt ein Sammelzeugnis einer Lehrveranstaltung DruckeSemPlan Druckt einen Semesterplan DruckeStudent Druckt eine Informationsliste bzgl. bestimmter Studenten Eingabe Öffnet ein Dialogfeld zur Tätigung einer Eingabe EKSpezifiziert Öffnet ein Dialogfeld zur Bestimmung einer Einstiegsklausur ErfassAnmeldung Öffnet ein Dialogfeld zur Erfassung von Anmeldungen ErzgLogEintrag Erzeugt einen Logbucheintrag FiltereEreignis Filtert bestimmte Benutzeraktionen FiltereFehler Filtert auftretende Fehler FrageBestätigt Öffnet ein Dialogfeld zur Bestätigung einer Frage HatDiplprfg Prüft einen Studenten auf positive Absolvierung einer Diplomprü-

fung Hilfe Öffnet ein Dialogfeld zur Anzeige einer Hilsmeldung IdentBenutzer Öffnet ein Dialogfeld zur Anmeldung eines Benutzers Information Öffnet ein Dialogfeld zur Anzeige einer Information IntFkt Liefert den ganzzahligen Anteil einer Dezimalzahl


Prozedur Bedeutung KonfigAnmeldung Öffnet einige Dialogfelder zur Konfiguration des Anmeldungsmodus Kurzstring Liefert eine gekürzte Zeichenkette Leerstring Liefert eine leere Zeichenkette LVASpezifiziert Öffnet ein Dialogfeld zur Bestimmung einer Lehrveranstaltung MarkLVAAlt Öffnet ein Dialogfeld zur Auswahl bestimmter Lehrveranstaltungen MarkLVADrk Öffnet ein Dialogfeld zur Auswahl bestimmter Lehrveranstaltungen MarkPersonal Öffnet ein Dialogfeld zur Auswahl bestimmter Institutsangehöriger MarkStudent Öffnet ein Dialogfeld zur Auswahl bestimmter Studenten Maximum Liefert den größeren zweier Werte Minimum Liefert den kleineren zweier Werte ÖffneFenster Öffnet ein leeres Fenster ÖffneStatistik Öffnet ein Dialogfeld zur Anzeige verschiedener Statistiken ÖffneÜberFISH Öffnet ein Dialogfeld zur Anzeige der Programminformation ÖffneZtrFenster Öffnet ein leeres, zentriertes Fenster PrüfeBenutzer Prüft den Benutzer auf Zugehörigkeit zu einer Benutzergruppe PrüfeTerminKoll Prüft Termine auf etwaige personelle oder räumliche Kollisionen ScheinSpezifzrt Öffnet ein Dialogfeld zur Bestimmung von Scheinen SemesterJahr Liefert die Jahreszahl eines Semesters SemesterTyp Liefert den Typ eines Semesters SetzeSystemVar Setzt eine Systemvariable SichereEinstkls Sichert die aktuelle Einstiegsklausur SichereLVA Sichert die aktuelle Lehrveranstaltung SichereLVATyp Sichert den aktuellen Lehrveranstaltungstyp SicherePersonal Sichert den aktuellen Institutsangehörigen SichereSemPlan Sichert den aktuellen Semesterplan SichereStudent Sichert den aktuellen Studenten SichereStudrcht Sichert die aktuelle Studienrichtung StartUp Führt verschiedene Initialisierungsaktionen aus SucheEinstkls Öffnet ein Dialogfeld zur Suche nach Einstiegsklausuren SucheLVA Öffnet ein Dialogfeld zur Suche nach Lehrveranstaltungen SucheStudent Öffnet ein Dialogfeld zur Suche nach Studenten SystemVar Liefert den Wert einer Systemvariable VerwltAnmeldung Öffnet ein Dialogfeld zur Verwaltung von Anmeldungen VerwltDiplprfg Öffnet ein Dialogfeld zur Verwaltung von Diplomprüfungen VerwltEinstklsr Öffnet ein Dialogfeld zur Verwaltung von Einstiegsklausuren VerwltFehlerptk Öffnet ein Dialogfeld zur Verwaltung von Fehlerprotokollen VerwltLogbuch Öffnet ein Dialogfeld zur Verwaltung des Logbuchs VerwltLVA Öffnet ein Dialogfeld zur Verwaltung von Lehrveranstaltungen VerwltLVATyp Öffnet ein Dialogfeld zur Verwaltung von Lehrveranstaltungstypen VerwltPersonal Öffnet ein Dialogfeld zur Verwaltung von Institutsangehörigen VerwltSchein Öffnet ein Dialogfeld zur Verwaltung von Scheinen VerwltSemPlan Öffnet ein Dialogfeld zur Verwaltung von Semesterplänen VerwltStudent Öffnet ein Dialogfeld zur Verwaltung von Studenten VerwltStudrchtg Öffnet ein Dialogfeld zur Verwaltung von Studienrichtungen


Prozedur Bedeutung VerwltSystemVar Öffnet ein Dialogfeld zur Verwaltung von Systemvariablen Wochenanfang Liefert den ersten Tag einer Woche Wochentag Liefert den Namen eines Wochentags

Tabelle V-25: Globale Prozeduren (Übersicht)

V.3.1.2 Die globale Prozedur AktLayVwlAnmldg Diese Prozedur ist für die Aktualisierung des Layouts LVA-Anmeldung verant-wortlich. Hier erfolgt die Suche und Sortierung der zugeordneten Anmeldun-gen, deren Anzahl wie die der Aufnahmen angezeigt werden muß. vLVA:=Suche in Tabelle(vSurrogat;[LVA]Surrogat) ZURÜCKGEHENDE VERKNÜPFUNG([LVA]) vAnzAnmeldg:=Datensätze in Auswahl([Anmeldung]) TEMPORÄRE AUSWAHL KOPIEREN([Anmeldung];"Anmeldung") SUCHE IN AUSWAHL([Anmeldung];[Anmeldung]Aufgenommen =Wahr) vAnzAufnahm:=Datensätze in Auswahl([Anmeldung]) TEMPORÄRE AUSWAHL BENUTZEN("Anmeldung") TEMPORÄRE AUSWAHL LÖSCHEN("Anmeldung") SORTIERE AUSWAHL([Anmeldung];[Student]Nachname;>)

V.3.1.3 Die globale Prozedur Auswahl Die Prozedur Auswahl ermöglicht dem Benutzer die Bestimmung eines Eintrags aus einer Liste. Diese Liste wird als Parameter übergeben und in das Layout [Dummy];"Auswahl" übernommen. Der Rückgabewert enthält die Positions-nummer der Selektion. `$0: Getroffene Auswahl `$1: Titel `$2: Auswahlliste C_GANZZAHL($zähler) TABELLE ALPHA(80;vListe;Tabellengröße($2»)) ÖffneZtrFenster (365;265;"Auswahl") vTitel:=$1 Für ($zähler;1;Tabellengröße($2»)) vListe{$zähler}:=$2»{$zähler} eFür DIALOG([Dummy];"Auswahl") Wenn (btnOK=1) $0:=vListe Sonst $0:=0

Systemdokumentation 102 eWenn

V.3.1.4 Die globale Prozedur DruckeStudent Vor dem Druck der Studentendaten werden die globalen Prozeduren MarkStu-dent zum Treffen einer Druckselektion bzw. Auswahl zur Bestimmung eines Drucklayouts aufgerufen. C_GANZZAHL($auswahl) TABELLE ALPHA(80;vDruckliste;2) Wenn (Datensätze in Datei([Student])>0) Wenn (AktionBestätigt ("Studentendaten drucken";" Bitte markieren Sie die auszugebenden Studenten.")) MarkStudent SUCHE([Student];[Student]Markiert=Wahr) Wenn (Datensätze in Auswahl([Student])>0) SORTIERE AUSWAHL([Student];[Student]MatrikelN r;>) vDruckliste{1}:="Name, Anschrift, Telefon" vDruckliste{2}:="Name, Scheine" $auswahl:=Auswahl ("Studentendaten drucken";» vDruckliste) vAktDatum:=Aktuelles Datum vBenutzer:=Aktueller Benutzer Im Falle : ($auswahl=1) AUSGABE LAYOUT([Student];"StammdatenDrk") : ($auswahl=2) AUSGABE LAYOUT([Student];"InformatLstDrk" ) eIm Falle Wenn ($auswahl>0) DRUCKE AUSWAHL([Student]) AUSGABE LAYOUT([Student];"Ausgabe") eWenn eWenn eWenn Sonst Information ("Keine Studenten";"Es existieren kei ne Studentendaten, sodaß kein Ausdruck erfolgen kann.") eWenn

V.3.1.5 Die globale Prozedur ErzgLogEintrag Logbucheinträge sind an den verschiedensten Stellen erforderlich, sodaß sich eine globale Prozedur anbietet, die auch gleich das aktuelle Datum und die ak-tuelle Uhrzeit einfügt. `$1: Transaktion ERZEUGE DATENSATZ([Logbuch]) [Logbuch]Datum:=Aktuelles Datum [Logbuch]Zeit:=Aktuelle Zeit [Logbuch]Transaktion:=$1 SICHERE DATENSATZ([Logbuch])


V.3.1.6 Die globale Prozedur FiltereEreignis Dieser Prozedur wird beim Programmstart die Filterung von Eingabeereignissen zugewiesen. Im speziellen wird die Tastenkombination Weiche-F abgefangen, die normalerweise ein Wechseln in den Benutzermodus erlauben würde, was bei Studenten als Benutzer nicht wünschenswert ist. Wenn ((Modifiers\2048%2=1 & (KeyCode=Ascii("ƒ")) Wenn (Aktueller Benutzer=SystemVar ("Benutzername Student")) EREIGNIS FILTERN ErzgLogEintrag ("Versuch in den Benutzermodus z u wechseln: "+ Aktueller Benutzer) Sonst ErzgLogEintrag ("In den Benutzermodus gewechsel t: "+Aktueller Benutzer) eWenn eWenn

V.3.1.7 Die globale Prozedur FiltereFehler Bei Zutagetreten eines Fehlers wird die weitere Programmsteuerung an FiltereFehler übergeben. Anders als bei der wenig aussagekräftigen Standard-Fehlermeldung können dadurch eine Beschreibung des Fehlers und möglicher Ursachen sowie Empfehlungen zur weiteren Vorgehensweise dargestellt wer-den. Ein Eintrag in das Fehlerprotokoll wird erzeugt und der Benutzer erhält die Möglichkeit, die näheren Umstände des Fehlerauftretens mitzudokumentieren. SUCHE([Fehler];[Fehler]Code=Error) Wenn (Datensätze in Auswahl([Fehler])=0) ERZEUGE DATENSATZ([Fehler]) [Fehler]Code:=Error [Fehler]Beschreibung:=Unbekannt SICHERE DATENSATZ([Fehler]) eWenn ERZEUGE DATENSATZ([Fehlerprotokoll]) [Fehlerprotokoll]Fehler:=[Fehler]Code [Fehlerprotokoll]Datum:=Aktuelles Datum [Fehlerprotokoll]Zeit:=Aktuelle Zeit SICHERE DATENSATZ([Fehlerprotokoll]) ÖffneZtrFenster (365;425;"Fehler") BEEP ÄNDERE DATENSATZ([Fehlerprotokoll];*)

V.3.1.8 Die globale Prozedur KonfigAnmeldung Zur Konfiguration des Anmeldungsmodus werden zunächst die Systemvariab-len AnmeldungDurchStudent und MinAlternativeAnmeldungen neu festgelegt.


Die Steuerung der Markierung alternativ angebotener Lehrveranstaltungen übernimmt die Prozedur MarkLVAAlt. SetzeSystemVar ("AnmeldungDurchStudent";FrageBestät igt ("Anmeldungsmodus"; "Soll die Anmeldung durch die Studenten selbst erfo lgen?"))) SetzeSystemVar ("MinAlternativeAnmeldungen"; Num(Eingabe ("Min. Anmeldungsprioritäten";"Wie viel e Prioritäten müssen bei der Anmeldung mindestens vergeben werden?"; String(SystemVar ("MinAlternativeAnmeldungen")))) Wenn (Datensätze in Datei([LVA])>0) Wenn (AktionBestätigt ("Alternativen bestimmen";" Bitte markieren Sie die zur Auswahl stehenden Lehrveranstaltungen.")) MarkLVAAlt eWenn Sonst Information ("Keine Lehrveranstaltungen";"Es exis tieren keine Lehrveranstaltungsdaten, sodaß auch keine "+"Anme ldungsalternativen bestimmt werden können.") eWenn

V.3.1.9 Die globale Prozedur LVASpezifiziert Die Prozedur LVASpezifiziert wird verwendet, um den Benutzer eine Lehrver-anstaltung aus einer vorgegebenen Auswahl bestimmen zu lassen; diese Lehr-veranstaltung wird zum aktuellen Datensatz. `$0: Wurde LVA spezifiziert? `$1: Titel `$2: ButtonText Wenn (Datensätze in Auswahl([LVA])>0) ÖffneFenster (575-SystemVar ("RollbalkenBreite"); 185-SystemVar ("RollbalkenBreite"); SystemVar ("StandardFensterTyp");$1;"") vTitel:=$1 vButtonText:=$2 DIALOG([LVA];"Spezifizierung") $0:=(btnOK=1) eWenn


V.3.1.10 Die globale Prozedur ÖffneFenster ÖffneFenster dient der Erzeugung eines Standardfensters. Ausmaße, Typ und Titel werden als Parameter übergeben, sodaß nur noch eine Anpassung an die aktuelle Bildschirmauflösung vorgenommen werden muß. `$1: Breite `$2: Höhe `$3: Typ `$4: Titel `$5: Schließen-Prozedur Wenn ($5="") $5:="BrichAb" eWenn ÖFFNE FENSTER(SystemVar ("FensterPositionX"); SystemVar ("FensterPositionY");Minimum (Bildschirmb reite;$1+ SystemVar ("RollbalkenBreite")+SystemVar ("FensterP ositionX")); Minimum (Bildschirmhöhe;$2+SystemVar ("RollbalkenBr eite")+ SystemVar ("FensterPositionY"));$3;$4;$5)

V.3.1.11 Die globale Prozedur PrüfeBenutzer Hat sich ein neuer Benutzer eingeloggt, so muß ein Logbucheintrag erzeugt und eine Anpassung der Menueleiste vorgenommen werden. ErzgLogEintrag ("Eingeloggt: "+Aktueller Benutzer) Wenn (Aktueller Benutzer=SystemVar ("BenutzernameSt udent")) MENULEISTE(2) Sonst MENULEISTE(1) eWenn

V.3.1.12 Die globale Prozedur PrüfeTerminKoll Die Kontrolle auf mögliche Terminkollisionen durch die globale Prozedur PrüfeTerminKoll erfolgt nach jeder Erstellung eines neuen bzw. Änderung eines bestehenden Termins. Die Verwendung von temporären Auswahlen ermöglicht es, sofort nach Beendigung der Überprüfung wieder die aktuelle Lehrveranstal-tung samt der ihr zugeordneten Termine im Layout anzuzeigen. C_GANZZAHL($lvaSurrogat;$lvaLeiter) C_DATUM($datum) C_ZEIT($beginn;$ende) C_ALPHA(20;$ort) Im Falle : (Danach) SICHERE DATENSATZ([Termin])

Systemdokumentation 106 $lvaSurrogat:=[Termin]LVA $lvaLeiter:=[LVA]Leiter $datum:=[Termin]Datum $beginn:=[Termin]Beginn $ende:=[Termin]Ende $ort:=[Termin]Ort TEMPORÄRE AUSWAHL AUSSCHNEIDEN([LVA];"LVA") TEMPORÄRE AUSWAHL AUSSCHNEIDEN([Termin];"Termin ")

Zuerst wird nach Terminen des selben Lehrveranstaltungsleiters gesucht, die in den zu betreffenden Zeitabschnitt fallen. Wurde ein Termin gefunden, erfolgt ein entsprechender Hinweis. SUCHE([LVA];[LVA]Leiter=$lvaLeiter) AUSWAHL ÜBERTRAGEN([Termin]LVA) SUCHE IN AUSWAHL([Termin];[Termin]LVA#$lvaSurro gat;*) SUCHE IN AUSWAHL([Termin]; & [Termin]Datum=$dat um;*) SUCHE IN AUSWAHL([Termin]; & [Termin]Beginn<$en de;*) SUCHE IN AUSWAHL([Termin]; & [Termin]Ende>$begi nn) Wenn (Datensätze in Auswahl([Termin])>0) LADE VERKNÜPFUNG([Termin]) SUCHE([Personal];[Personal]Surrogat=[LVA]Leit er) Information ("Terminkollision";"Der Lehrveran staltungsleiter "+ [Personal]Titel+" "+[Personal]Vorname+" "+[Pe rsonal]Nachname+ " leitet am "+String([Termin]Datum)+" von "+ Zeitstring([Termin]Beginn)+"h bis "+Zeitstrin g([Termin]Ende)+ "h bereits die Lehrveranstaltung "+[LVA]Bezei chnung+".")

Ganz ähnlich läuft die Suche nach Terminen zur selben Zeit im selben Raum ab. Sonst Wenn ($ort#"") SUCHE([Termin];[Termin]LVA#$lvaSurrogat;*) SUCHE([Termin]; & [Termin]Datum=$datum;*) SUCHE([Termin]; & [Termin]Beginn<$ende;*) SUCHE([Termin]; & [Termin]Ende>$beginn;*) SUCHE([Termin]; & [Termin]Ort=$ort) Wenn (Datensätze in Auswahl([Termin])>0) LADE VERKNÜPFUNG([Termin]) Information ("Terminkollision";"Der Raum "+[Termin]Ort+ " ist am "+String([Termin]Datum)+" in der Zeit von "+ Zeitstring([Termin]Beginn)+"h bis "+Zeits tring([Termin]Ende)+ "h durch die Lehrveranstaltung "+[LVA]Bez eichnung+" belegt.") eWenn eWenn eWenn TEMPORÄRE AUSWAHL BENUTZEN("LVA") TEMPORÄRE AUSWAHL BENUTZEN("Termin") TEMPORÄRE AUSWAHL LÖSCHEN("LVA") TEMPORÄRE AUSWAHL LÖSCHEN("Termin") SCHLIESSE FENSTER eIm Falle


V.3.1.13 Die globale Prozedur SetzeSystemVar SetzeSystemVar ist eine Zugriffsfunktion auf Systemvariablen. Da Parameter in 4th Dimension nicht typgebunden sind, ist es insofern vorerst gleichgültig, ob es sich dabei um Zeichenketten, Zahlen oder Wahrheitswerte handelt; diese Un-terscheidung wird erst intern anhand des Attributs [SystemVar]Typ vorgenom-men. [SystemVar]Wert ist notwendigerweise ein String, um Variablenwerte al-ler drei Typen in der Datenbasis ablegen zu können. `$1: Bezeichner `$2: Wert SUCHE([SystemVar];[SystemVar]Bezeichner=$1) Im Falle : ([SystemVar]Typ="String") [SystemVar]Wert:=$2 : ([SystemVar]Typ="Integer") [SystemVar]Wert:=String($2) : ([SystemVar]Typ="Boolean") Wenn ($2) [SystemVar]Wert:="Wahr" Sonst [SystemVar]Wert:="Falsch" eWenn eIm Falle SICHERE DATENSATZ([SystemVar])

V.3.1.14 Die globale Prozedur SichereStudent Die Speicherung von Studenten (gleiches gilt für Lehrveranstaltungen, Lehrve-ranstaltungstypen, Personal, Einstiegsklausuren und Studienrichtungen) erfolgt nicht nur bei expliziter Aufforderung durch den Benutzer, sondern auch bei Be-tätigung verschiedener anderer Buttons, sodaß dafür eine globale Prozedur not-wendig ist. Hier wird auch eine Aktualisierung von [Student]GeändertDatum vorgenommen. C_ALPHA(7;$matrikelNr) C_GANZZAHL($deltaIndex) Wenn ([Student]MatrikelNr#"") Wenn (Datensatz geändert([Student])) Wenn ([Student]ErstelltDatum=!00.00.00!) [Student]ErstelltDatum:=Aktuelles Datum eWenn [Student]GeändertDatum:=Aktuelles Datum SICHERE DATENSATZ([Student]) ErzgLogEintrag ("Student gespeichert: Matrikel- Nr: "+ [Student]MatrikelNr+", Kennzahl: "+[Student]Ken nzahl+", Name: "+ [Student]Nachname+" "+[Student]Vorname) vStatus:="Student gespeichert"

Systemdokumentation 108 Sonst vStatus:="Speicherung nicht nötig" eWenn Sonst vStatus:="Speicherung mangels Angabe der Matrikel nummer nicht möglich" eWenn

Der folgende Abschnitt ist von Bedeutung, wenn in Folge einer Suche oder der Erzeugung eines neuen Datensatzes nur ein Student in der Auswahl vorliegt, jedoch mehrere in der Datenbasis vorhanden sind. Dann ergibt sich nämlich das Problem, wie der Benutzer wieder auf die restlichen Daten Zugriff erhält, ohne daß der aktuelle Datensatz dabei verlorengeht. Eine Möglichkeit bestünde über den Umweg des Suchdialogs, der aber beispielsweise für die Institutsangestell-ten gar nicht vorgesehen ist. Nachdem jedoch eine Sortierung (hier: nach Matrikelnummer) der Daten vorliegt, kann durch binäres Suchen sowie über den Befehl GEHE ZUM AUSGEWÄHLTEN DATENSATZ Abhilfe geschaffen werden - und das äußerst rasch. Wenn ((Datensätze in Auswahl([Student])=1) & (Datensätze in Datei([Student])>1)) $matrikelNr:=[Student]MatrikelNr ALLE DATENSÄTZE([Student]) SORTIERE AUSWAHL([Student];[Student]MatrikelNr;>) $deltaIndex:=Runde(Datensätze in Auswahl([Student ])/2;0) GEHE ZUM AUSGEWÄHLTEN DATENSATZ([Student];$deltaI ndex) Solange ([Student]MatrikelNr#$matrikelNr) $deltaIndex:=Runde($deltaIndex/2;0) Wenn ([Student]MatrikelNr<$matrikelNr) GEHE ZUM AUSGEWÄHLTEN DATENSATZ([Student]; Ausgewählter Datensatz([Student])+$deltaIndex ) Sonst GEHE ZUM AUSGEWÄHLTEN DATENSATZ([Student]; Ausgewählter Datensatz([Student])-$deltaIndex ) eWenn eSolange eWenn

V.3.1.15 Die globale Prozedur StartUp Die Prozedur StartUp wird von 4th Dimension standardmäßig beim Programm-start ausgeführt. Neben einigen Initialisierungsanweisungen wird hier v.a. für die Aktualisierung der Dateien Semester und Diplomprüfung, auf die der Be-nutzer ja keinen direkten Zugriff hat, gesorgt. C_GANZZAHL($jahr) MELDUNGEN AUS RUFE BEI EREIGNIS("FiltereEreignis") RUFE BEI FEHLER("FiltereFehler")

Systemdokumentation 109 PrüfeBenutzer ÄNDERE FENSTERTITEL("F.I.S.H.") SetzeSystemVar ("StatistikBerechnet";Falsch) SetzeSystemVar ("DetailstatistikBerechnet";Falsch) Wenn ((Datensätze in Datei([Semester])#((Jahr von(A ktuelles Datum)- SystemVar ("StartJahr")+2)*2) | (Datensätze in Date i([Diplomprüfung])# ((Jahr von(Aktuelles Datum)-SystemVar ("StartJahr") +2)*4)) Für ($jahr;SystemVar ("StartJahr");Jahr von(Aktue lles Datum)+1) SUCHE MIT FORMEL([Semester]; (SemesterJahr ([Semester]Bezeichnung)=Mod($jahr ;100))) Wenn (Datensätze in Auswahl([Semester])#2) LÖSCHE AUSWAHL([Semester]) ERZEUGE DATENSATZ([Semester]) [Semester]Bezeichnung:="SS "+String(Mod($jahr ;100)) SICHERE DATENSATZ([Semester]) ERZEUGE DATENSATZ([Semester]) [Semester]Bezeichnung:="WS "+String(Mod($jahr ;100)) SICHERE DATENSATZ([Semester]) eWenn SUCHE MIT FORMEL([Diplomprüfung];(Teilstring([D iplomprüfung]Termin; Länge([Diplomprüfung]Termin)-1)=String(Mod($jah r;100)))) AUSWAHL ÜBERTRAGEN([DiplprfgErgeb]Termin) Wenn (Datensätze in Auswahl([DiplprfgErgeb])=0) LÖSCHE AUSWAHL([Diplomprüfung]) SUCHE([SystemVar];[SystemVar]Bezeichner="Dipl omprüfungTermin[@]") Wenn (Datensätze in Auswahl([SystemVar])>0) SORTIERE AUSWAHL([SystemVar];[SystemVar]Bez eichner;>) Solange (Nicht(Nach der Auswahl([SystemVar] )) ERZEUGE DATENSATZ([Diplomprüfung]) [Diplomprüfung]Termin:=[SystemVar]Wert+" "+String(Mod($jahr;100)) SICHERE DATENSATZ([Diplomprüfung]) NÄCHSTER DATENSATZ([SystemVar]) eSolange eWenn eWenn eFür eWenn btnAlle:=0

V.3.1.16 Die globale Prozedur VerwltStudent Ähnliche Prozeduren wie diese stehen hinter jedem Menuepunkt zur Stammda-tenverwaltung. Wichtig ist hier die Abfrage auf vorhandene Datensätze, um je nachdem mittels der Befehle ÄNDERE DATENSATZ bzw. NEUER DATENSATZ das Eingabelayout aufrufen zu können. ÖffneFenster (575;435;SystemVar ("StandardFensterTy p"); "Studenten verwalten";"") Wenn (Datensätze in Datei([Student])>0)

Systemdokumentation 110 ALLE DATENSÄTZE([Student]) SORTIERE AUSWAHL([Student];[Student]MatrikelNr;>) ÄNDERE DATENSATZ([Student]) Sonst NEUER DATENSATZ([Student]) eWenn

V.3.2 Layoutprozeduren V.3.2.1 Übersicht Datei Layout Bedeutung Anmeldung EingebdLVA Aktualisierung von Studenten-

Datumsangaben Erfassung Initialisierung der Anzeige Diplomprüfung Druck Sortierung von Diplomprüfungsergebnissen Eingabe Initialisierung der Anzeige Spezifizierung Initialisierung der Anzeige DiplprfgErgeb EingebdDiplprfg Aktualisierung von Studenten-

Datumsangaben Dummy Fehlerprotokoll Initialisierung der Anzeige Logbuch Initialisierung der Anzeige MarkLVADruck Initialisierung der Anzeige MarkLVAAlt Initialisierung der Anzeige MarkPersonal Initialisierung der Anzeige MarkStudent Initialisierung der Anzeige Statistik Initialisierung der Anzeige SystemVar Initialisierung der Anzeige Einstklsr Eingabe Initialisierung und Aktualisierung der Anzei-

ge ExternDrk Suche nach und Sortierung von Einstiegs-

klausurergebnissen InternDrk Sortierung von Einstiegsklausurergebnissen Spezifizierung Initialisierung der Anzeige Suche Initialisierung der Anzeige EinstklsrErgeb EingebdEinstkls Aktualisierung von Studenten-

Datumsangaben LVA AnmeldeLstDrk Sortierung von Anmeldungen Anmeldung Initialisierung und Aktualisierung der Anzei-

ge AnwesenhLstDrk Generierung von Zeittafeln AufnahmeLstDrk Suche nach und Sortierung von Anmeldun-

gen Druck Ermittlung des Standardtermins


Datei Layout Bedeutung Eingabe Initialisierung und Aktualisierung der Anzei-

ge ErgebnlstExtDrk Sortierung von Scheinen ErgebnlstIntDrk Suche nach und Sortierung von Lehrveran-

staltungsergebnissen SammelzgnDrk Suche nach und Sortierung von Lehrveran-

staltungsergebnissen Schein Initialisierung und Aktualisierung der Anzei-

ge Spezifizierung Initialisierung der Anzeige Suche Initialisierung der Anzeige LVATyp Eingabe Initialisierung und Aktualisierung der Anzei-

ge Personal Druck Ermittlung der Anschrift Eingabe Initialisierung und Aktualisierung der Anzei-

ge Schein EingebdLVA Aktualisierung von Studenten-

Datumsangaben Spezifizierung Initialisierung der Anzeige Semesterplan Druck Sortierung von Lehrveranstaltungen Eingabe Sortierung von Lehrveranstaltungen Spezifizierung Initialisierung der Anzeige SpezifizierungD Initialisierung der Anzeige Student Eingabe Initialisierung und Aktualisierung der Anzei-

ge StammdatenDrk Ermittlung der Anschrift Suche Initialisierung der Anzeige Studienrichtung Eingabe Initialisierung und Aktualisierung der Anzei-

ge Zeittafel EingebdSemPl Aktualisierung der Anzeige EingebdSemPlDrk Aktualisierung der Anzeige

Tabelle V-26: Layoutprozeduren (Übersicht)

V.3.2.2 Die Layoutprozedur LVA-Anmeldung Die Prozedur LVA-Anmeldung soll beispielhaft für zahlreiche ähnlich geartete Layoutprozeduren erläutert werden, die für die Initialisierung der Bildschirm-darstellung in der Bevor- bzw. deren Aktualisierung in der Während-Phase ve-rantwortlich sind. Hier werden zunächst die substantiellen Lehrveranstaltungs-daten in einem Popup abgelegt. Anfänglich soll der letzte Datensatz angezeigt werden.


C_GANZZAHL($zähler) Im Falle : (Bevor) ALLE DATENSÄTZE([LVA]) TABELLE GANZZAHL(vSurrogat;Datensätze in Datei( [LVA])) TABELLE ALPHA(100;vLVA;Datensätze in Datei([LVA ])) $zähler:=1 Solange (Nicht(Nach der Auswahl([LVA]))) LADE VERKNÜPFUNG([LVA]) vSurrogat{$zähler}:=[LVA]Surrogat vLVA{$zähler}:=String(Num([LVA]Nummer);"###.# ##")+ " "+[LVA]Semester+" "+Kurzstring ([LVA]Kürz el;2)+" "+ Kurzstring ([LVA]Bezeichnung;35)+" "+ Kurzstring ([Personal]Nachname;12) NÄCHSTER DATENSATZ([LVA]) $zähler:=$zähler+1 eSolange LETZTER DATENSATZ([LVA]) AktLayVwlAnmldg vStatus:=""

Die Während-Phase wird bei jeder Benutzeraktion aufgerufen. Was im speziel-len bei einem Mausklick auf einen der verschiedenen Buttons zu tun ist, steht in den entsprechenden Skripts. Auf jeden Fall muß die Anzeige aktualisiert wer-den; das übernimmt die Prozedur AktLayVwlAnmldg. : (Während) Im Falle : (btnAufnahme=1) | (btnErster=1) | (btnVorhe rig=1) | (btnSuchen=1) | (btnAlle=1) | (btnNächster=1) | (btnLetzter =1)) AktLayVwlAnmldg eIm Falle eIm Falle

V.3.2.3 Die Layoutprozedur LVA-SammelzgnDrk Prozeduren zu Drucklayouts sorgen meist nur für eine Straffung bzw. Sortie-rung von bereits spezifizierten Ausgabedaten. Für ein Sammelzeugnis etwa wä-ren ursprünglich - da das Layout der Datei LVA zugeordnet ist - alle Scheine dieser Lehrveranstaltung auszudrucken. Diese Auswahl ist aber auf ein be-stimmtes Prüfungsdatum sowie u.U. auf Systemplanungs- bzw. Informations-wirtschaftsstudenten einzugrenzen; desweiteren sollen die Scheine nach Nach-namen sortiert werden.

Systemdokumentation 113 Im Falle : (Bevor) SUCHE IN AUSWAHL([Schein]; [Schein]Prüfungsdatum=Datum(vPrfgDatum{vPrfgDat um})) Im Falle : (vSystemplan=1) SUCHE IN AUSWAHL([Schein];[Studienrichtung] Fachrichtung=Wahr) : (vInfoWirt=1) SUCHE IN AUSWAHL([Schein];[Studienrichtung] Fachrichtung=Falsch) eIm Falle SORTIERE AUSWAHL([Schein];[Student]Nachname;>) eIm Falle

V.3.3 Dateiprozeduren V.3.3.1 Übersicht Dateiprozedur Bedeutung Anmeldung Erzeugung eines Logbucheintrags DiplprfgErgeb Erzeugung eines Logbucheintrags EinstklsrErgeb Erzeugung eines Logbucheintrags Schein Erzeugung eines Logbucheintrags

Tabelle V-27: Dateiprozeduren (Übersicht)

V.3.3.2 Die Dateiprozedur Anmeldung Dateiprozeduren werden nach jedem Schreibzugriff auf eine Datei in einem Eingabe- oder einem eingebundenen Layout aufgerufen und bieten sich daher für die Erzeugung entsprechender Logbucheinträge an. Im Falle : (Danach) ErzgLogEintrag ("Anmeldung gespeichert: LVA-Sur rogat: "+ String([Anmeldung]LVA)+", Matrikel-Nr: "+ [Anmeldung]MatrikelNr+", Priorität: "+String([A nmeldung]Priorität)) eIm Falle


V.4 Menues Es stehen zwei verschiedene Menueleisten zur Verfügung, die den Erfordernis-sen der unterschiedlichen Benutzergruppen angepaßt wurden. Menueleiste Benutzergruppen Funktionen

1 Design Institut

Alle

2 Studenten Über F.I.S.H... Beenden Anmeldungen erfassen

Tabelle V-28: Menueleisten

V.5 Kennwörter Das Informationssystem differenziert zwischen den Benutzergruppen • Design • Institut • Studenten Mitglieder des Design-Teams haben die meisten Zugriffsrechte, v.a. auch in be-zug auf Daten- und Programmstrukturen. Institutsangehörige können den vollen Funktionsumfang und den Benutzermodus nutzen, um dort eigene Abfragen auf der Datenbasis auszuführen. Ein Wechseln in den Designmodus bleibt ihnen hingegen ebenso verwehrt wie Schreib/Leseoperationen auf bestimmte Dateien. Den Studenten zuguterletzt wird von vornherein nur ein stark eingeschränkter Befehlsschatz angeboten. Sie können auch unter keinen Umständen in den Be-nutzermodus gelangen.

Quellenverzeichnis

Quellenverzeichnis Bischoff, Krallmann: „Reengineering - Mit alten Zutaten zu neuen Konzepten“, in: Mertens, Hasenkamp: „Wirtschaftsinformatik 2/92“, Vieweg & Sohn Ver-lagsgesellschaft, Braunschweig/Wiesbaden 1992, S. 125-126 Frazer, A.: „Reverse-Engineering - hype, hope or here“, in: Hall, P.: „Software Reuse and Reverse-Engineering in Practice“, Chapman & Hall, London 1992 Heinrich, Lehner, Roithmayr: „Informations- und Kommunikationstechnik“, 3. Auflage, R. Oldenbourg Verlag, München/Wien 1993 Heinrich, Roithmayr: „Wirtschaftsinformatik-Lexikon“, 4. Auflage, R. Oldenbourg Verlag, München/Wien 1992 Kaufmann, A.: „Software-Reengineering: Analyse, Restrukturierung und Re-verse-Engineering von Anwendungssystemen“, R. Oldenbourg Verlag, Mün-chen/Wien 1994 Krallmann, Wöhrle: „Marktübersicht CARE-Tools“, in: Mertens, Hasenkamp: „Wirtschaftsinformatik 2/92“, Vieweg & Sohn Verlagsgesellschaft, Braun-schweig/Wiesbaden 1992, S. 181-189 Pomberger, Blaschek: „Software Engineering“, Carl Hanser Verlag, Mün-chen/Wien 1993 Reindl, M.: „Re-Engineering des Datenmodells“, in: Schmitz, Szyperski, Mer-tens: „Wirtschaftsinformatik 4/91“, Vieweg & Sohn Verlagsgesellschaft, Braunschweig/Wiesbaden 1991, S. 281-289 Richter, L.: „Wiederbenutzbarkeit und Restrukturierung oder Reuse, Reengineering und Reverse-Engineering“, in: Mertens, Hasenkamp: „Wirt-schaftsinformatik 2/92“, Vieweg & Sohn Verlagsgesellschaft, Braun-schweig/Wiesbaden 1992, S. 127-136 Thurner, R.: „ReEngineering und Innovation in der Anwendungsentwicklung“, in: Kurbel, K.: „Wirtschaftsinformatik ‘93“, Physica Verlag, Heidelberg 1993, S. 39-52