SlideShare une entreprise Scribd logo

Diplomarbeit: Software Reengineering (1995)

•
•
Arno Huetter
Arno Huetter

Software Reengineering

Logiciels
1  sur  125
Télécharger pour lire hors ligne
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ß 1 Vgl. Kaufmann, A.: „Software-Reengineering“, S. 1 2 Vgl. Bischoff, Krallmann: „Reengineering“, S. 125 3 Vgl. 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 Adaption Extraktion Abstraktion 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 4 Vgl. Richter, L.: „Wiederbenutzbarkeit und Restrukturierung oder Reuse, Reengineering und Reverse Engineering“, S. 128
Grundlagen des Reengineering 4 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 5 Reindl, M.: „Re-Engineering des Datenmodells“, S. 282 6 Vgl. ebenda 7 Vgl. Heinrich, Roithmayer: „Wirtschaftsinformatik-Lexikon“, S. 446 8 Vgl. Richter, a.a.O, S. 128 9 Vgl. Frazer, A.: „Reverse-Engineering - hype, hope or here?“, S. 215
Grundlagen des Reengineering 5 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 10 Vgl. Kaufmann, A.: a.a.O, S. 10 11 Pomberger, Blascheck: „Software Engineering“, S. 18
Grundlagen des Reengineering 6 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 12 Vgl. Kaufmann, A.: a.a.O, S. 8f 13 Vgl. ebenda, S. 10 14 Vgl. Thurner, R.: „ReEngineering und Innovation in der Anwendungsentwick- lung“, S. 39f
Grundlagen des Reengineering 7 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. 15 Vgl. Thurner, R.: a.a.O, S. 40
Grundlagen des Reengineering 8 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. 16 Vgl. Kaufmann, A.: a.a.O, S. 24ff
Grundlagen des Reengineering 9 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 Zielsystem Zwischen- code Abstraktes Modell 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. 17 Vgl. ebenda, S. 32f 18 Ebenda, S. 33
Grundlagen des Reengineering 10 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 19 Vgl. Thurner, R.:a.a.O, S. 45ff
Grundlagen des Reengineering 11 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. 20 Vgl. Kaufmann, A.: a.a.O, S. 34f 21 Ebenda, S. 45
Grundlagen des Reengineering 12 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 22 Vgl. ebenda, S. 34 23 Vgl. ebenda, S. 45f
Grundlagen des Reengineering 13 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.
Grundlagen des Reengineering 14 Für jedes ökonomisch motivierte Vorgehen muß eine klare Ziel-Ergebnis- Vorgehensweise-Struktur formuliert werden. Ziel Ergebnis Vorgehen Hoher Wartbarkeitsgrad Lesbare Programmquellen Vollständige Dokumentation 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 24 Vgl. ebenda, S. 81 25 Vgl. ebenda, S. 78ff
Grundlagen des Reengineering 15 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. 26 Vgl. ebenda, S. 82ff
Grundlagen des Reengineering 16 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 27 Vgl. Heinrich, Lehner, Roithmayr: „Informations- und Kommunikationstech- nik“, S. 334 28 Ebenda
Grundlagen des Reengineering 17 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 29 Vgl. 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]Studenten_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-Surrogat: "+ 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]Matr_Nr) SEARCH SELECTION([Prüfungen];[Prüfungen]Sur_LVA=$LVA) waren nunmehr obsolet, nachdem die Suchfunktion etwaige Indizierungen automatisch berücksichtigt. Die Befehlsfolge SUCHE([Schein];[Schein]LVA=[LVA]Surrogat;*) SUCHE([Schein]; & [Schein]MatrikelNr=[Anmeldung]MatrikelNr) 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 1 1 Einstiegsklausur betrifft n 1 ScheinAnmeldung erhält n 1 n tätigt 1 betrifft Lehrveran- staltung n 1 n betrifft 1 Semesterplan Lehrveranstal- tungstyp hat 1 n Termin hat 1 n Lehrveranstal- tungsleiter leitet 1nEingangs- voraussetzung hat n 1 hat n 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 Lehrveranstal- tungstyp 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 Lehrveranstal- tungstyp Lehrveranstal- tungsleiter leitet 1n hat n 1 Student LVA Schein betrifft erhält 1 n n 1 Student Schein erhält n 1 betrifft Lehrveran- staltung n 1 Lehrveranstal- tungstyp Lehrveranstal- tungsleiter leitet 1n hat n 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)
Benutzerdokumentation 37 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.
Benutzerdokumentation 38 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.
Benutzerdokumentation 39 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.
Benutzerdokumentation 40 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.
Benutzerdokumentation 41 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.
Benutzerdokumentation 42 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
Benutzerdokumentation 43 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-
Benutzerdokumentation 44 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
Benutzerdokumentation 45 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.
Benutzerdokumentation 46 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.
Benutzerdokumentation 47 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.
Benutzerdokumentation 48 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.
Benutzerdokumentation 49 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.
Benutzerdokumentation 50 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).
Benutzerdokumentation 51 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
Benutzerdokumentation 52 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.
Benutzerdokumentation 53 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.
Benutzerdokumentation 54 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.
Benutzerdokumentation 55 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.
Benutzerdokumentation 56 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.
Benutzerdokumentation 57 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.
Benutzerdokumentation 58 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.
Benutzerdokumentation 59 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.
Benutzerdokumentation 60 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.
Benutzerdokumentation 61 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.
Benutzerdokumentation 62 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-
Benutzerdokumentation 63 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.
Benutzerdokumentation 64 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.
Benutzerdokumentation 65 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.
Benutzerdokumentation 66 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.
Benutzerdokumentation 67 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.
Benutzerdokumentation 68 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.
Benutzerdokumentation 69 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
Benutzerdokumentation 70 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.
Systemdokumentation 72 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
Systemdokumentation 73 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
Systemdokumentation 74 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
Systemdokumentation 75 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
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)
Diplomarbeit: Software Reengineering (1995)

Recommandé

Fallstudie: Wie ein deutsches Stadtwerk mit Social Listening die Kundenbindun...
Fallstudie: Wie ein deutsches Stadtwerk mit Social Listening die Kundenbindun...Fallstudie: Wie ein deutsches Stadtwerk mit Social Listening die Kundenbindun...
Fallstudie: Wie ein deutsches Stadtwerk mit Social Listening die Kundenbindun...Talkwalker
 
Chess Engine Programming
Chess Engine ProgrammingChess Engine Programming
Chess Engine ProgrammingArno Huetter
 
Abraham Lincoln
Abraham LincolnAbraham Lincoln
Abraham LincolnArno Huetter
 
Augustus
AugustusAugustus
AugustusArno Huetter
 
The world's most famous programmers
The world's most famous programmersThe world's most famous programmers
The world's most famous programmersArno Huetter
 
Geschichte des Computers (1991)
Geschichte des Computers (1991)Geschichte des Computers (1991)
Geschichte des Computers (1991)Arno Huetter
 
Grundlagen der Volkswirtschaftslehre (1993)
Grundlagen der Volkswirtschaftslehre (1993)Grundlagen der Volkswirtschaftslehre (1993)
Grundlagen der Volkswirtschaftslehre (1993)Arno Huetter
 
Database Performance Tuning
Database Performance Tuning Database Performance Tuning
Database Performance Tuning Arno Huetter
 

Recommandé

Fallstudie: Wie ein deutsches Stadtwerk mit Social Listening die Kundenbindun...
Fallstudie: Wie ein deutsches Stadtwerk mit Social Listening die Kundenbindun...Fallstudie: Wie ein deutsches Stadtwerk mit Social Listening die Kundenbindun...
Fallstudie: Wie ein deutsches Stadtwerk mit Social Listening die Kundenbindun...Talkwalker
 
Chess Engine Programming
Chess Engine ProgrammingChess Engine Programming
Chess Engine ProgrammingArno Huetter
 
Abraham Lincoln
Abraham LincolnAbraham Lincoln
Abraham LincolnArno Huetter
 
Augustus
AugustusAugustus
AugustusArno Huetter
 
The world's most famous programmers
The world's most famous programmersThe world's most famous programmers
The world's most famous programmersArno Huetter
 
Geschichte des Computers (1991)
Geschichte des Computers (1991)Geschichte des Computers (1991)
Geschichte des Computers (1991)Arno Huetter
 
Grundlagen der Volkswirtschaftslehre (1993)
Grundlagen der Volkswirtschaftslehre (1993)Grundlagen der Volkswirtschaftslehre (1993)
Grundlagen der Volkswirtschaftslehre (1993)Arno Huetter
 
Database Performance Tuning
Database Performance Tuning Database Performance Tuning
Database Performance Tuning Arno Huetter
 
Diplomarbeit: Generische und dynamische Hypertexte (2001)
Diplomarbeit: Generische und dynamische Hypertexte (2001)Diplomarbeit: Generische und dynamische Hypertexte (2001)
Diplomarbeit: Generische und dynamische Hypertexte (2001)Arno Huetter
 
Leading Software Development Teams
Leading Software Development TeamsLeading Software Development Teams
Leading Software Development TeamsArno Huetter
 
Windows Debugging with WinDbg
Windows Debugging with WinDbgWindows Debugging with WinDbg
Windows Debugging with WinDbgArno Huetter
 
Software Disasters
Software DisastersSoftware Disasters
Software DisastersArno Huetter
 
The History of the PC
The History of the PCThe History of the PC
The History of the PCArno Huetter
 
Führen von Software-Entwicklungsteams
Führen von Software-EntwicklungsteamsFühren von Software-Entwicklungsteams
Führen von Software-EntwicklungsteamsArno Huetter
 

Contenu connexe

Plus de Arno Huetter

Diplomarbeit: Generische und dynamische Hypertexte (2001)
Diplomarbeit: Generische und dynamische Hypertexte (2001)Diplomarbeit: Generische und dynamische Hypertexte (2001)
Diplomarbeit: Generische und dynamische Hypertexte (2001)Arno Huetter
 
Leading Software Development Teams
Leading Software Development TeamsLeading Software Development Teams
Leading Software Development TeamsArno Huetter
 
Windows Debugging with WinDbg
Windows Debugging with WinDbgWindows Debugging with WinDbg
Windows Debugging with WinDbgArno Huetter
 
Software Disasters
Software DisastersSoftware Disasters
Software DisastersArno Huetter
 
The History of the PC
The History of the PCThe History of the PC
The History of the PCArno Huetter
 
Führen von Software-Entwicklungsteams
Führen von Software-EntwicklungsteamsFühren von Software-Entwicklungsteams
Führen von Software-EntwicklungsteamsArno Huetter
 

Plus de Arno Huetter (6)

Diplomarbeit: Generische und dynamische Hypertexte (2001)
Diplomarbeit: Generische und dynamische Hypertexte (2001)Diplomarbeit: Generische und dynamische Hypertexte (2001)
Diplomarbeit: Generische und dynamische Hypertexte (2001)
 
Leading Software Development Teams
Leading Software Development TeamsLeading Software Development Teams
Leading Software Development Teams
 
Windows Debugging with WinDbg
Windows Debugging with WinDbgWindows Debugging with WinDbg
Windows Debugging with WinDbg
 
Software Disasters
Software DisastersSoftware Disasters
Software Disasters
 
The History of the PC
The History of the PCThe History of the PC
The History of the PC
 
Führen von Software-Entwicklungsteams
Führen von Software-EntwicklungsteamsFühren von Software-Entwicklungsteams
Führen von Software-Entwicklungsteams
 

Diplomarbeit: Software Reengineering (1995)

  • 1. 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
  • 2. 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)
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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ß 1 Vgl. Kaufmann, A.: „Software-Reengineering“, S. 1 2 Vgl. Bischoff, Krallmann: „Reengineering“, S. 125 3 Vgl. ebenda
  • 12. 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.
  • 13. 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 Adaption Extraktion Abstraktion 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 4 Vgl. Richter, L.: „Wiederbenutzbarkeit und Restrukturierung oder Reuse, Reengineering und Reverse Engineering“, S. 128
  • 14. Grundlagen des Reengineering 4 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 5 Reindl, M.: „Re-Engineering des Datenmodells“, S. 282 6 Vgl. ebenda 7 Vgl. Heinrich, Roithmayer: „Wirtschaftsinformatik-Lexikon“, S. 446 8 Vgl. Richter, a.a.O, S. 128 9 Vgl. Frazer, A.: „Reverse-Engineering - hype, hope or here?“, S. 215
  • 15. Grundlagen des Reengineering 5 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 10 Vgl. Kaufmann, A.: a.a.O, S. 10 11 Pomberger, Blascheck: „Software Engineering“, S. 18
  • 16. Grundlagen des Reengineering 6 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 12 Vgl. Kaufmann, A.: a.a.O, S. 8f 13 Vgl. ebenda, S. 10 14 Vgl. Thurner, R.: „ReEngineering und Innovation in der Anwendungsentwick- lung“, S. 39f
  • 17. Grundlagen des Reengineering 7 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. 15 Vgl. Thurner, R.: a.a.O, S. 40
  • 18. Grundlagen des Reengineering 8 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. 16 Vgl. Kaufmann, A.: a.a.O, S. 24ff
  • 19. Grundlagen des Reengineering 9 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 Zielsystem Zwischen- code Abstraktes Modell 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. 17 Vgl. ebenda, S. 32f 18 Ebenda, S. 33
  • 20. Grundlagen des Reengineering 10 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 19 Vgl. Thurner, R.:a.a.O, S. 45ff
  • 21. Grundlagen des Reengineering 11 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. 20 Vgl. Kaufmann, A.: a.a.O, S. 34f 21 Ebenda, S. 45
  • 22. Grundlagen des Reengineering 12 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 22 Vgl. ebenda, S. 34 23 Vgl. ebenda, S. 45f
  • 23. Grundlagen des Reengineering 13 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.
  • 24. Grundlagen des Reengineering 14 Für jedes ökonomisch motivierte Vorgehen muß eine klare Ziel-Ergebnis- Vorgehensweise-Struktur formuliert werden. Ziel Ergebnis Vorgehen Hoher Wartbarkeitsgrad Lesbare Programmquellen Vollständige Dokumentation 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 24 Vgl. ebenda, S. 81 25 Vgl. ebenda, S. 78ff
  • 25. Grundlagen des Reengineering 15 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. 26 Vgl. ebenda, S. 82ff
  • 26. Grundlagen des Reengineering 16 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 27 Vgl. Heinrich, Lehner, Roithmayr: „Informations- und Kommunikationstech- nik“, S. 334 28 Ebenda
  • 27. Grundlagen des Reengineering 17 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 29 Vgl. Krallmann, Wöhrle: „Marktübersicht CARE-Tools“, S. 183ff
  • 28. 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
  • 29. 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
  • 30. 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-
  • 31. 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]Studenten_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
  • 32. 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-Surrogat: "+ 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]Matr_Nr) SEARCH SELECTION([Prüfungen];[Prüfungen]Sur_LVA=$LVA) waren nunmehr obsolet, nachdem die Suchfunktion etwaige Indizierungen automatisch berücksichtigt. Die Befehlsfolge SUCHE([Schein];[Schein]LVA=[LVA]Surrogat;*) SUCHE([Schein]; & [Schein]MatrikelNr=[Anmeldung]MatrikelNr) 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-
  • 33. 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.
  • 34. 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.
  • 35. 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
  • 36. 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.
  • 37. 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.
  • 39. 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 Lehrveranstal- tungstyp 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 Lehrveranstal- tungstyp Lehrveranstal- tungsleiter leitet 1n hat n 1 Student LVA Schein betrifft erhält 1 n n 1 Student Schein erhält n 1 betrifft Lehrveran- staltung n 1 Lehrveranstal- tungstyp Lehrveranstal- tungsleiter leitet 1n hat n 1 Tabelle III-1: Die relevanten Modelltransformationen
  • 40. 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
  • 41. 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.
  • 42. 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.
  • 43. 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.
  • 44. 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
  • 45. 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.
  • 46. 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)
  • 47. Benutzerdokumentation 37 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.
  • 48. Benutzerdokumentation 38 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.
  • 49. Benutzerdokumentation 39 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.
  • 50. Benutzerdokumentation 40 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.
  • 51. Benutzerdokumentation 41 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.
  • 52. Benutzerdokumentation 42 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
  • 53. Benutzerdokumentation 43 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-
  • 54. Benutzerdokumentation 44 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
  • 55. Benutzerdokumentation 45 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.
  • 56. Benutzerdokumentation 46 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.
  • 57. Benutzerdokumentation 47 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.
  • 58. Benutzerdokumentation 48 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.
  • 59. Benutzerdokumentation 49 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.
  • 60. Benutzerdokumentation 50 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).
  • 61. Benutzerdokumentation 51 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
  • 62. Benutzerdokumentation 52 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.
  • 63. Benutzerdokumentation 53 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.
  • 64. Benutzerdokumentation 54 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.
  • 65. Benutzerdokumentation 55 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.
  • 66. Benutzerdokumentation 56 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.
  • 67. Benutzerdokumentation 57 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.
  • 68. Benutzerdokumentation 58 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.
  • 69. Benutzerdokumentation 59 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.
  • 70. Benutzerdokumentation 60 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.
  • 71. Benutzerdokumentation 61 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.
  • 72. Benutzerdokumentation 62 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-
  • 73. Benutzerdokumentation 63 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.
  • 74. Benutzerdokumentation 64 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.
  • 75. Benutzerdokumentation 65 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.
  • 76. Benutzerdokumentation 66 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.
  • 77. Benutzerdokumentation 67 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.
  • 78. Benutzerdokumentation 68 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.
  • 79. Benutzerdokumentation 69 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
  • 80. Benutzerdokumentation 70 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.
  • 81. 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.
  • 82. Systemdokumentation 72 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
  • 83. Systemdokumentation 73 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
  • 84. Systemdokumentation 74 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
  • 85. Systemdokumentation 75 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