Erweiterung des webbasierten Verwaltungssystems für Internationale Hochschulkooperationen

Transkript

1 Erweiterung des webbasierten Verwaltungssystems für Internationale Hochschulkooperationen Extending the web based administration system for co-operations with universities on an international level Paul Molitor Bachelor Abschlussarbeit Betreuer: Prof. Dr. Ing. Georg Schneider Trier,

2 Zusammenfassung in Deutsch II Zusammenfassung in Deutsch Gegenstand dieser Abschlussarbeit ist die Anpassung des webbasierten Verwaltungssystems für Internationale Hochschulkooperationen der Fachhochschule Trier zu einem mehrbenutzerfähigen System, also Design und Implementierung der neuen Datenbankstruktur sowie des neuen Backends. Als Datenbank wird ein PostgreSQL-Server verwendet, als HTML-Generator kommt die Script-Sprache PHP zum Einsatz, die Benutzerauthentifizierung wird über LDAP abgewickelt und die Backend-Inhalte werden mit einer Kombination aus PHP und PL/PGSQL- Funktionen generiert und clientseitig zum Teil mit Javascript aufbereitet. Der Technische Aspekt der Arbeit behandelt, wie das Konzept der mehrbenutzer- Fähigkeit mit PostgreSQL-Mitteln (PL/PGSQL Funktionen und Triggern) umgesetzt wurde, wie das Backend die Komplexität des Datenmodells abstrahiert, und wie Javascript zur grundlegenden Änderung der Bedienung eingesetzt werden kann, ohne dass Javascript zu einer Voraussetzung zur Bedienung wird. Abstract in English This work focuses on the modification of the system for managing international university cooperations (as used by the Univeristy of Applied Sciences of Treves) to meet the requirements of a multi-user environment. This modification mostly consists of designing and implementing a new database structure as well as a matching new administration backend. The system employs a PostgrSQL database server, the scripting language PHP for generating HTML content, and the scripting language PL/PGSQL, used for parts of the data collecting and for most of the user rights management. Additionally, the system employs client side Javascript to improve the ease of use of the Backend. The technical view on this work explores how the multi user concept can be implemented with PostgreSQL features like PL/PGSQL Functions and Triggers, how the backend hides the complexity of the data model, and how Javascript is used to facilitate the use of the backend while at the same time not depending on Javascript.

3 Inhaltsverzeichnis III Inhaltsverzeichnis 1 Einleitung Motivation Ziele der Arbeit Grundlegende Konzepte PostgreSQL Skriptsprachen PHP Javascript & DOM LDAP Konzept Userinterface zum Anlegen eines Studienangebotes Benutzerrechte Behandlung von verwaisten Elementen in der Datenbank Realisierung Authentifizierung und Rechteverwaltung Benutzerführung im Backend Einfügen eines neuen Studienangebotes Interaktion mit der Datenbank Automatisches Entfernen von verwaisten Daten Aktualisierung der Währungen Beispiel Resümee und Ausblick Literaturverzeichnis Anhang... 42

4 Einleitung 4 1 Einleitung 1.1 Motivation Hochschulen wollen die Mobilität ihrer Studenten fördern, indem sie ihren Studenten die Möglichkeit von Auslandssemestern an anderen Hochschulen bieten. Damit ein solches Auslandssemester zustande kommt, muss mit der Hochschule, an welcher dieses Auslandssemester zustande kommen soll, eine Vereinbarung existieren. Eine Hochschule pflegt viele derartige Vereinbarungen mit unterschiedlichen Hochschulen und zu potentiell unterschiedlichen Konditionen. Da die Fachrichtung bei einem Austausch relevant ist, finden die Vereinbarungen genauer betrachtet nicht direkt zwischen Hochschulen, sondern zwischen den Fachbereichen der Hochschulen statt. Diese Vielzahl an unterschiedlichen und unabhängigen Vereinbarungen verlangt nach einer übersichtlichen Verwaltungsmöglichkeit. Eine solche Verwaltungsmöglichkeit für die Fachhochschule Trier soll in dieser Abschlussarbeit geschaffen werden. Zusätzlich erlaubt ein solches Verwaltungssystem interessierten Studenten einen direkten Überblick über mögliche Ziele für ein Auslandssemester. 1.2 Ziele der Arbeit Ziel der Arbeit ist ein vorhandenes Verwaltungssystem (in [Hermes] erstellt) derart anzupassen, dass Mitarbeiter aus mehreren Fachbereichen unabhängig voneinander ihre Hochschulvereinbarungen im System verwalten können. Obwohl die Mitarbeiter auf teilweise überschneidenden Daten arbeiten, sollen ihre Inhalte vor Manipulation durch Mitarbeiter anderer Fachbereiche geschützt sein. Es soll ein Konzept zur Benutzerrechteverwaltung entwickelt werden, das diese Anforderungen erfüllt. Ein Kriterium der Umsetzung ist, dass ein direkter Eingriff in die Datenbank nicht zu Inkonsistenzen im Datenmodell führen kann und keine verwaisten Daten hinterlässt. Die Arbeit umfasst zusätzlich die Entwicklung eines Backends, das die Komplexität des Datenmodells abstrahiert und eine intuitive Bedienung ermöglicht.

5 Grundlegende Konzepte 5 2 Grundlegende Konzepte 2.1 PostgreSQL PostgreSQL ist ein objektrelationales Datenbankverwaltungssystem ( object-relational database management system ), kurz ORDBMS, und entspricht der unter der BSD Lizenz weiterentwickelten Version der an der University of California vom Berkeley Computer Science Department entwickelten Postgres 4.2 [PostgreSQL 2008a]. PostgreSQL unterstützt einen Grossteil des SQL-Standards, so unter anderem komplexe SQL-Abfragen, Fremdschlüssel, Trigger, Views, transaktionale Integrität, gleichzeitiges Arbeiten an den gleichen Daten (multiversion concurrency control), sowie über den SQL-Standard hinausgehende Funktionen und prozeduralen Sprachen (procedual Langauges, kurz PL). [PostgreSQL 2008a]. Ein Trigger ist eine Anweisung an die Datenbank, vor, beziehungsweise nach Änderungen an einer konkreten Tabelle eine vorgegebene Funktion auszuführen. Bei diesen Funktionen handelt es sich um PostgreSQL-Funktionen mit speziellem Rückgabewert TRIGGER. [PostgrSQL 2008b] Neben ihrem Einsatz in Triggern können PostgreSQL-Funktionen in SQL- Abfragen verwendet werden. Abhängig von ihrem Rückgabewert lässt sich eine PostgreSQL-Funktion in einer SQL-Abfrage auf Felder (columns) anwenden, oder SQL- Abfragen können auf PostgreSQL-Funktionen ausgeführt werden als handele es sich bei ihnen um Tabellen. Funktionen haben Effizienz-Vorteile gegenüber normalen SQL- Abfragen. PostgreSQL kompiliert Funktionen nach dem ersten Aufruf, so dass weitere Aufrufe dieser Funktion beschleunigt ablaufen. Auch sind Funktionen effizienter, wenn mehr als eine SQL-Abfrage ausgeführt werden soll. In Funktionen können nämlich mehrere Anfragen am Stück ausgeführt werden, die Kontrolle muss nicht nach jeder Anfrage an den Client zurückgeben werden, damit dieser die nächste Abfrage sendet. [PostgreSQL 2008c]. Den für die vorliegende Arbeit relevantesten Vorteil stellt der zusätzliche Level an Abstraktion dar, denn durch Funktionen kann ein Teil der Programmlogik vom Client auf den Server verlagert werden.

6 Grundlegende Konzepte 6 Funktionen beugen auch vor SQL-Injection vor, da übergebene Parameter nur als Werte in SQL-Abfragen eingesetzt werden können. (Ausnahme: Wenn die Funktion eine mittels String-Operationen aus Variablen zusammensetzte Abfrage erstellt und mit EXE- CUTE ausführt, ist SQL-Injection trotzdem möglich). PostgreSQL-Funktionen können in SQL oder in einer von vielen prozeduralen Sprachen geschrieben werden, etwa in PL/pgSQL, der eigenen prozeduralen Sprache von PostreSQL, oder auch in PL/TCL, in PL/Perl, oder in PL/Python. [PostgreSQL 2008d]. Zusätzlich sind weitere Sprachen nachrüstbar, etwa PL/Java. [PostgreSQL 2008e]. PL/pgSQL enthält in Programmiersprachen gängige Befehlsstrukturen wie Schleifen (LOOP) und Weichen (IF-THEN-ELSE). In [PostgreSQL 2008f] wird der Vergleich mit der Programmiersprache C gezogen: Except for input/output conversion and calculation functions for user-defined types, anything that can be defined in C language functions can also be done with PL/pgSQL. In der vorliegenden Arbeit werden PostgreSQL- Funktionen exklusiv mit PL/pgSQL umgesetzt. In der Vorliegenden Arbeit kommt PostgreSQL in der Version zum Einsatz. 2.2 Skriptsprachen Das Konzept von Skriptsprachen weicht von dem von echten Programmiersprachen insoweit ab, als dass sie nicht wie Programmiersprachen einmalig zu Binärcode gewandelt (kompiliert) werden, um auf dem Prozessor ausgeführt zu werden, sondern zur Laufzeit ausgewertet (interpretiert) werden. Durch diese Eigenart sind in Skriptsprachen programmierte Vorgänge langsamer als zu einem Programm kompilierte Vorgänge. Den Nachteil der Verarbeitungsgeschwindigkeit kompensieren Skriptsprachen durch andere Vorteile, etwa dass sie meist abstrakter sind und dadurch mit weniger Code zum gleichen Ziel führen können. Weitere Vorteile sind die Fähigkeit, Funktionen dynamisch zur Laufzeit generieren zu können, sowie die Freiheit, Datentypen von Variablen zur Laufzeit anpassen zu können, etwa das Vergrößern eines Feldes. [TCL 2008]. Ob eine Skriptsprache diese Vorteile auch zulässt hängt von der verwendeten Skriptsprache ab.

7 Grundlegende Konzepte PHP PHP (ein rekursives Akronym für PHP: Hypertext Preprocessor ) ist eine open-source Scriptsprache. PHP lässt sich für mehrere Zwecke einsetzen, eignet sich jedoch am besten für den Einsatz in der Webentwicklung, da es in Hypertext-Dokumenten (wie HTML) eingebettet werden kann. In HTML-Dateien wird dieses Einbetten durch Beginn- und Schluss-Tags signalisiert, zwischen diese wird der PHP-Code eingefügt. So kann eine statische Seite an genau den gewünschten Stellen um dynamische Inhalte erweitert werden, und nur diese müssen vom PHP-Parser ausgewertet werden. [PHP 2008a] Der PHP-Code wird auf dem Server ausgewertet, der Client, etwa ein Webbrowser, erhält nur das fertig generierte Resultat. Zur Inhaltsbeschaffung unterstützt PHP die Kommunikation mit einer Reihe von Datenbankservern (unter anderem PostgreSQL), sowie anderen Techniken (unter anderem LDAP) [PHP 2008b]. In der vorliegenden Arbeit kommt PHP in der Version zum Einsatz. 2.4 Javascript & DOM Javascript ist eine von Netscape entwickelte Skriptsprache. Laut [Mozilla 2008] kommt sie am häufigsten in Webbrowsern zum Einsatz. In Webbrowsern wird Javascript genutzt, um vom Webserver gelieferten Code zur Laufzeit auszuführen. Javascript wird clientseitig ausgeführt und kann ohne spürbare Verzögerung Wirkung zeigen. Deswegen lassen sich Funktionalitäten realisieren, die mit einer serverseitigen Ausführung nur schlecht denkbar wären. Der Nachteil der clientseitigen Ausführung ist, dass aus Serversicht einer von Javascript geprüften oder einer durch Javascript generierten Rückgabe nicht ohne serverseitige Prüfung getraut werden kann. Schließlich liegt der Browser außerhalb der Kontrolle des Servers und kann beliebiger Manipulation ausgesetzt sein. Das Document Object Model, kurz DOM, stellt den Aufbau einer HTML-Seite in einer Baumstruktur dar. Knoten im Baum entsprechen unter anderem Text oder HTML- Tags. Knoten haben Eigenschaften, und im Fall von HTML-Tags können Knoten auch Unterknoten haben.

8 Grundlegende Konzepte 8 Das DOM ist unabhängig von Javascript. Weil Javascript Funktionen zum Zugriff auf das DOM enthält und in Webseiten ausschließlich zur Modifikation des Doms dient, wird das DOM dennoch geläufig als Teil von Javascript behandelt. [Quirksmode 2006] 2.5 LDAP Das Lightweight Directory Access Protocol, kurz LDAP, ist wie sein Name beschreibt ein schlanker Kommunikationsstandard zum Zugriff auf Datenverzeichnisse. Ein Datenverzeichnis ist eine Datenbank, in welcher Daten in einer Baumstruktur angeordnet sind, vergleichbar mit der Anordnung von Dateien in einem Dateiverzeichnis. LDAP verwendet wie SQL eine textbasierte Sprache um Abfragen zu formulieren. Wie in SQL- Abfragen existiert bei LDAP-Abfragen die Möglichkeit, mit Kriterien Resultate ein- oder auszuschließen, die Suche auf einen Teil der Daten zu beschränken (mit Angabe des Pfades in der Baumstruktur), oder nur bestimmte Felder im Resultat zu erhalten. [PHP 2008c] LDAP-Verzeichnisse finden meist Einsatz um Adressbuch-artige Daten zu verwalten, etwa ein -Verzeichnis für Programme, oder Informationen von Mitarbeitern in einer Firma, etwa Zugriffsrechte und Kontaktdaten. Letzteres entspricht auch dem Einsatzzweck des LDAP-Servers an der Fachhochschule Trier, so dass die Zugangsauthentifizierung des in dieser Arbeit entwickelten Verwaltungssystems über LDAP abgewickelt werden kann.

9 Konzept 9 3 Konzept 3.1 Userinterface zum Anlegen eines Studienangebotes Situation und Problemstellung Ein Studienangebot ist definiert als ein Programm (zum Beispiel ein Abschluss oder ein Praktikum) an einer Einrichtung einer Hochschule. Im Datenmodell ist ein Studienangebot also eine eindeutige Kombination aus einem Programm und einer Hochschuleinrichtung. Eine Einrichtung gehört zu einer Hochschule, und eine Hochschule hat ein Land und eine Sprache. Ein Studienangebot hat zwei obligatorische Eigenschaften, nämlich mindestens einen Betreuer an der eigenen Hochschule (den internen Betreuer ), und mindestens einen Vertrag, welchem dieses Studienangebot unterliegt. Weitere Eigenschaften des Studienangebotes sind optional, etwa Voraussetzungen um dieses Studienangebot als Student in Anspruch nehmen zu können, Terme (Laufzeiten der Semester), externe Betreuer (Betreuer an der Hochschule des Studienangebotes), Erfahrungsberichte von Studenten, die dieses Studienangebot bereits in Anspruch genommen haben, oder eine Währung zu einer Gebühr, sofern das Studienangebot gebührenpflichtig ist. Abbildung 3-1 zeigt die Relationen dieser Elemente in einem Diagramm. Im Anhang dieser Arbeit zeigt Abbildung 7-1 ein ER-Diagramm der Datenstruktur mit allen Eigenschaften.

10 Konzept 10 Land Sprache Hochschule Abschluss Einrichtung Studienangebot Vertrag Interner Betreuer Währung Erfahrungsbericht Externer Betreuer Term Voraussetzung Referenz NM-Assoziation muss - Verbindung kann - Verbindung Abbildung 3-1: Datenmodell des Systems Die komplexen Relationen verlangen nach einem Konzept, das dem Benutzer erlaubt, neue Studienangebote anzulegen, ohne dass der Benutzer den internen Aufbau des Datenmodells mitsamt seinen Abhängigkeiten kennen muss alle Elemente einzeln anlegen Ein Konzept wäre, den Anwender jedes Element einzeln anlegen zu lassen. Diese Möglichkeit ist jedoch aus mehreren Gründen unpassend. Der Benutzer müsste verkehrt herum arbeiten, denn wollte er ein neues Studienangebot anlegen, müsste er zuerst dafür sorgen, dass das passende Programm, der passenden Vertrag, der passende interne Mitarbeiter und die passende Hochschuleinrichtung vorhanden seien. Und wäre die Hochschuleinrichtung nicht vorhanden, müsste er vergleichbar auch für die passende Hochschule sorgen, welche wiederum die passende Sprache und das passende Land benötigen.

11 Konzept 11 Dieses Vorgehen verlangt dem Benutzer nicht nur eine genaue Kenntnis der Datenstruktur ab, es ist auch unbequem, weil unübersichtlich. Ob Unterelemente fehlen, stellt sich erst heraus, wenn versucht wird, ein darauf aufbauendes Element anzulegen. Außerdem verhindert dieses Konzept die Vorgabe, dass das System frei von unbenutzten Daten bleiben soll, weil Elemente zum Zeitpunkt des Anlegens grundsätzlich noch nicht von anderen Elementen verwendet werden. Ob der Benutzer ein angelegtes Element anschließend auch nutzen wird, ist für das System nicht feststellbar. Der Benutzer könnte also beliebige Elemente anlegen ohne sie zu nutzen Verwendung eines Wizards Das Konzept des Wizards löst beide Probleme, sowohl die unintuitive Bedienung, wie auch die Möglichkeit, dass sich unbenutzte Daten erstellen lassen. Ein Wizard ist ein Bedienungskonzept, das den Benutzer in Schritten mit fest definierter Reihenfolge durch alle nötigen Einstellungen leitet. Durch die Unterteilung in Schritte lassen sich Abhängigkeiten des Datenmodells vor dem Benutzer verbergen. Eingaben des aktuellen Schrittes können genutzt werden, um im nächsten Schritt nur Auswahlmöglichkeiten bereit zu stellen, die zu den Einstellungen aus dem aktuellen Schritt passen. [UIE 1997]. Dank dem Wizard muss der Benutzer sich keine Gedanken machen ob er an alles gedacht hat und er braucht keine Kenntnis vom unterliegenden Datenmodell zu haben. In jedem Schritt wird ein Element-Typ des Datenmodells behandelt, etwa das Land, die Sprache, oder die Hochschule. Der Benutzer steht in einem Schritt vor der Frage, ob das von ihm zu verwendende Element schon vorhanden ist oder nicht. Ist es vorhanden, wählt er es aus einer Liste aus, andernfalls muss er es neu anlegen. Im nächsten Schritt wiederholt sich die Situation für den nächsten Element-Typ. Wenn die Wahl des aktuellen Elementes abhängig von dem Element aus dem vorigen Schritt ist, werden dem Benutzer nur Elemente zur Auswahl gestellt, die die Abhängigkeit zur Auswahl im vorigen Schritt erfüllen. Hat der Benutzer zum Beispiel ein neues Land angelegt, kann es noch keine Hochschule mit diesem Land geben, der Benutzer kann also bei der Auswahl der Hochschule nur eine neue Hochschule anlegen. Hat der Benutzer hingegen ein vorhandenes Land gewählt, hat er anschließend neben der Möglichkeit, eine neue Hochschule anzulegen, auch die Möglichkeit eine Hochschule aus der Liste der vorhandenen und zu dem

12 Konzept 12 ausgewählten Land passenden Hochschulen auszuwählen. Schritte zwischen welchen keine Abhängigkeit besteht können auch zu einem Schritt vereint werden. Wenn der Wizard Daten nach Schritten nur zwischenspeichert und sie erst nach einem fehlerfreien Durchlauf des Wizards festschreibt, wird auch das Anlegen von nicht verwendeten Elementen unmöglich. Dies ist ein weiterer Vorteil gegenüber dem ersten Konzept. Abbildung 3-2 verdeutlicht das Eingabekonzept des Wizards am Beispiel der dieser Arbeit zugrunde liegenden Datenstruktur. neues Studienangebot anlegen: Schritt 1: Land auswählen oder neu anlegen. Sprache auswählen oder neu anlegen. Land oder Sprache neu angelegt? Nein Ja Schritt 2: Hochschule auswählen (aus Liste mit Hochschulen die zu ausgewähltem Land und Sprache passen) oder neu anlegen Hochschule neu anlegen Hochschule neu angelegt? Nein Ja Ja Schritt 3: Einrichtung auswählen (aus Liste mit Einrichtungen die zur ausgewählten Hochschule passen) oder neu anlegen Einrichtung neu anlegen Schritt 4: Programm auswählen oder neu anlegen. Optional Währung auswählen oder neu anlegen. Schritt 5: 1 - N Verträge auswählen und/oder neu anlegen. 1 - N interne Betreuer auswählen und/oder anlegen. Schritt 6: (optional) 0 - N Voraussetzungen auswählen und/oder neu anlegen. 0 - N Terme auswählen und/oder neu anlegen. 0 - N externe Betreuer auswählen und/oder neu anlegen. Abbildung 3-2: Eingabekonzept des Wizards

13 Konzept Benutzerrechte Situation und Probleme Elemente sollen nicht mehrfach im System vorhanden sein, es soll zum Beispiel nur ein Land mit dem Wert England geben. Soll es mehrere Hochschulen mit dem Land England geben, müssen sie also das gleiche Land-Element verwenden. Über diese Eindeutigkeit von Elementen wacht die Datenbank. Tabellen in der Datenbank sind derart definiert, dass kein zweites Element mit gleichem Wert eingefügt werden kann. Gleichzeitig soll ein Benutzer selbst angelegte Elemente bearbeiten können. Diese Gegebenheiten können zu Konflikten führen und verlangen nach einem Konzept, das den Benutzern ihre Rechte einräumt, und dennoch verhindert, dass mit diesen Rechten Studienangebote anderer Benutzer negativ beeinflusst werden können. Ein Beispiel soll einen solchen Konflikt illustrieren: was passiert, wenn ein Benutzer eine von ihm angelegte Hochschule wieder löschen will? In Zwischenzeit könnten Studienangebote von anderen Benutzern diese Hochschule verwenden. Könnte der Benutzer die Hochschule löschen, würden alle Einrichtungen und damit indirekt alle Studienangebote gelöscht, die diese Hochschule verwenden, egal welchem Benutzer sie gehören Das Konzept Jeder Benutzer gehört einer Gruppe an. Diese Gruppe kann stellvertretend für einen Fachbereich sein, für das System ist die Bedeutung der Gruppe jedoch irrelevant. Gruppen bieten lediglich einen Abstraktionslevel, damit mehrere Benutzer mit den gleichen Rechten arbeiten können, sofern dies erwünscht ist. Um das Konzept zu erläutern, eignet es sich, bei den im Datenmodell vorhandenen Tabellen zwischen Elementen (in der Abbildung 3-1 als Rechtecke dargestellt) und reinen Assoziationstabellen (in der Abbildung 3-1 als Kreise dargestellt) zu unterscheiden. Zu jedem Element (mit Ausnahme des Erfahrungsberichtes) ist die Gruppe des Benutzers gespeichert, der dieses Element angelegt hat. Zu Erfahrungsberichten und zu Einträgen in Assoziationstabellen werden keine Gruppeninformationen gespeichert. Sie gehören genau einem Studienangebot an, weshalb für sie die Rechte des Studienangebotes gelten. Abbildung 7-2 im Anhang dieser Arbeit zeigt ein ER-Diagramm aller Rechtetabellen in Relation zu den Datentabellen.

14 Konzept 14 Ein von einem Benutzer angelegtes Element wird fortan als sein Element bezeichnet. Ein Benutzer kann seine Elemente modifizieren, nicht aber löschen. Eine Sonderrolle spielen Studienangebote und Erfahrungsberichte. Ein Erfahrungsbericht gehört genau einem Studienangebot an, er kann nur vom Erzeuger des Studienangebotes angelegt worden sein, weshalb der Erzeuger des Studienangebotes einen zugehörigen Erfahrungsbericht nicht nur bearbeiten, sondern auch löschen darf. Ein Benutzer darf außerdem sein eigenes Studienangebot löschen, da ein Studienangebot das höchste Element ist und als solches von keinem anderen Element verwendet werden kann. Alle anderen Elemente kann ein Benutzer nicht löschen. Was der Benutzer hingegen löschen kann, sind die Assoziationen zu seinen Studienangeboten. (Ein Benutzer darf genau dann eine Assoziation zu einem Studienangebot löschen, wenn er das Studienangebot bearbeiten darf). Wählt der Benutzer zum Beispiel, eine Voraussetzung aus seinem Studienangebot zu entfernen, wird nur die Assoziation dieser Voraussetzung zu diesem Studienangebot gelöscht. Das eigentliche Vorrausetzungs-Element bleibt im System erhalten. Beim Löschen eines Studienangebotes werden analog alle Assoziationen zu diesem Studienangebot, sowie die diesem Studienangebot assoziierten Rechte gelöscht. Alle vom Studienangebot verwendeten Elemente bleiben beim Löschen des Studienangebotes erhalten. Es ist offensichtlich, dass die Anzahl der unbenutzten Elemente nach diesem Konzept mit der Zeit wächst. Dieser Problematik nimmt sich Kapitel 3.3 an. 3.3 Behandlung von verwaisten Elementen in der Datenbank Wie in beschrieben, dürfen Benutzer zu keinem Zeitpunkt Elemente löschen. (Ausnahmen stellen Studiengänge und Erfahrungsberichte dar). Einmal erstellte Elemente würden also in der Datenbank erhalten bleiben, die Datenbank würde im Laufe der Zeit einen immer größeren Anteil an unbenutzten Elementen enthalten. Grundsätzlich kann ein Element als nicht mehr benötigt angesehen werden, wenn es von keinem anderen Element mehr verwendet wird. Das Überprüfen und Löschen von solchen Elementen lässt sich leicht feststellen und somit automatisieren. Das System löscht automatisch alle Elemente, die nicht mehr von anderen Elementen verwendet werden. Dieser Vorgang läuft ohne Rücksprache oder Benachrichtigung an den Benutzer ab,

15 Konzept 15 denn wenn das Element nicht mehr verwendet wird, verwendet es auch der Benutzer nicht, der es angelegt hat. Es wird der Fall eintreten, dass ein Benutzer ein von ihm angelegtes Element aktuell nicht braucht, aber später wieder brauchen wird. In dem Fall muss der Benutzer das Element wieder neu anlegen. Dies ist ein akzeptabler Kompromiss, denn nur so wird gewährt dass die Datenbank frei von unbenutzten Elementen bleibt. Außerdem enthält kein Elementtyp mehr als sechs Informationen, wird ein Element wieder benötigt ist es schnell erneut angelegt. Trotzdem ist es Sinnvoll, alle Benutzer über dieses Konzept in Kenntnis zu setzen, so dass sie im Falle des Falles zuerst das neue Studienangebot anlegen bevor sie den alten löschen. Abbildung 3-3 zeigt, wie das Löschen eines Elementes die automatisierte Prüfung auf Löschung weiterer Elemente anstößt. Land Sprache Hochschule Abschluss Einrichtung Studienangebot Vertrag Währung Interner Betreuer Erfahrungsbericht Externer Betreuer Term Voraussetzung Referenz NM-Assoziation muss - Verbindung kann - Verbindung A B Löschen von A feuert Prüfung, ob B noch benutzt wird oder gelöscht werden kann. Abbildung 3-3: Progpagation der Prüfung auf automatisches Löschen

16 Realisierung 16 4 Realisierung Die Benutzung des Systems durch Benutzer findet ausschließlich über ein Webinterface statt. Dieses ist in PHP programmiert, nutzt Javascript zur Unterstützung des Benutzers, und greift auf eine PostgreSQL-Datenbank sowie einen LDAP-Server zu. Die Administration der Benutzer findet direkt in der Datenbank statt, weshalb das Backend keine Funktionen zum Administrieren von Benutzern benötigt. 4.1 Authentifizierung und Rechteverwaltung Das Backend verlangt zur Benutzung eine Authentifizierung. Zugang zum Backend sollen nur Mitarbeiter erhalten, die mit ihrer Mitarbeiternummer im System registriert sind. Die Authentifizierung verläuft intern in drei Schritten. Der Benutzer authentifiziert sich mit Login und Passwort seines Hochschulzuganges. Das System wertet diese Informationen nicht selber aus, sondern baut mit ihnen in einem ersten Schritt eine Verbindung zu dem LDAP-Server der Fachhochschule Trier auf. Kommt die Verbindung zustande, ist sichergestellt, dass die Zugangsdaten korrekt sind. Zu diesem Zeitpunkt ist aber noch nicht gewährt, dass es sich beim Benutzer um einen Mitarbeiter handelt, es könnte sich auch um einen Studenten handeln. Deshalb wird in einem zweiten Schritt mit einer LDAP-Abfrage über die zuvor aufgebaute LDAP-Verbindung die Mitarbeiternummer des Benutzers ermittelt. (Nur Mitarbeiter besitzen eine Mitarbeiternummer). Im dritten und letzten Schritt wird geprüft, ob die Mitarbeiternummer im System einer Gruppe angehört. Ist dies der Fall, ist die Authentifizierung erfolgreich abgeschlossen, und der Benutzer hat Zugriff auf das Backend. Eine Mitarbeiternummer gehört genau einer Gruppe an. Gruppen können stellvertretend für Fachbereiche genutzt werden, sie haben im System aber keine spezielle Bedeutung. Gruppen erbringen lediglich eine Abstraktionsschicht zwischen Benutzer und Daten, und ermöglichen als solche, Rechte eines Benutzers auf einen anderen Benutzer zu übertragen, oder mehreren Benutzern die gleichen Rechte zu geben, ohne dass diese mit den gleichen Zugangsdaten arbeiten müssten. Außerdem kann die Zugehörigkeit einer Mitarbeiternummer zu einer Gruppe als Freischaltung betrachtet werden, da Benutzer nur Zugang zum System haben, wenn ihre Mitarbeiternummer einer Gruppe zugehört.

17 Realisierung 17 Da die Anzahl der Backend-Benutzer klein ist und die Benutzer im System selten wechseln, existiert für die Zuordnung von Mitarbeiternummern zu Gruppen kein grafisches Benutzerinterface. Sie werden nach Bedarf vom Datenbank-Administrator direkt in der Datenbank angelegt. Die Zugehörigkeit von Mitarbeiternummer zu Gruppe ist übrigens die einzige Information, die das System zu einem Benutzer speichert. Wird eine neue Gruppe angelegt, haben alle Benutzer, die dieser Gruppe zugewiesen werden, erstmal keine Rechte. Rechte ergeben sich erst beim Anlegen von Elementen. Legt ein Benutzer ein neues Studienangebot an, haben alle Mitglieder seiner Gruppe fortan das Recht, dieses Studienangebot zu ändern oder zu löschen. Wurden beim Anlegen des Studienangebotes auch andere Elemente angelegt, etwa ein Land das zuvor nicht vorhanden war, haben alle Mitglieder dieser Gruppe auch das Recht, dieses Land zu ändern. Die so erhaltenen Rechte werden der Gruppe zugeschrieben. Wird ein Benutzer in eine andere Gruppe versetzt, erhält er die Rechte der neuen Gruppe und verliert seine vorigen Rechte. Diese Rechte verbleiben bei der vorigen Gruppe, auch wenn Aktivitäten des Benutzers der Ursprung dieser Rechte waren. Ob ein Recht einräumt, ein Element nur bearbeiten oder auch löschen zu dürfen, erschließt sich nicht aus der Art des Rechtes, sondern aus der Art des Elements, an welchem das Recht gehalten wird. Nur Elemente der Typen Studienangebot und Erfahrungsbericht können von Hand gelöscht werden. Für diese zwei Typen bedeutet ein Recht, das Element bearbeiten oder löschen zu können. Für alle anderen Typen entspricht ein Recht nur dem Recht des Bearbeitens. Die Möglichkeit des Löschens dieser Elemente wird nicht nur im Backend nicht angeboten, das Datenmodell wurde so in der Datenbank umgesetzt, dass die Datenbank das Löschen von Elementen überhaupt nicht zulässt, wenn andere Elemente sie noch referenzieren. In der Detailansicht eines Studienangebotes hat ein Benutzer scheinbar das Recht, Elemente der Typen Voraussetzung, Term, Vertrag, interner Benutzer und externer Benutzer zu löschen. Hierbei handelt es sich aber nicht um das Recht, diese Elemente zu löschen, sondern um das Recht, das Studienangebot zu bearbeiten. Es werden dann auch keine Elemente gelöscht, sondern nur deren Assoziationen zu dem Studienangebot entfernt.

18 Realisierung 18 Mehrere Gruppen können auch Rechte am selben Element halten. Bis auf eine spezielle Ausnahme existiert aber kein Mechanismus, der ein Element automatisch mehreren Gruppen zuordnen würde. Die besagte Ausnahme ist, dass beim Erstellen eines jeden Elementes neben der Gruppe des Erstellers auch die vordefinierte Admingruppe eingetragen wird. Diese Admingruppe wird folglich Rechte an allen angelegten Elementen halten. Dieser Ansatz realisiert eine Admingruppe, ohne dass diese im System einer Sonderbehandlung bedarf. Außer bei dem Anlegen von Elementen kann das System sie ohne Kenntnis von ihrer Sonderrolle wie eine normale Gruppe behandeln. 4.2 Benutzerführung im Backend Das Backend ist nach Funktionalität in fünf Seiten unterteilt, von welchen zwei direkt über das Menu erreichbar sind. Über das Menu lässt sich einerseits der Wizard zum anlegen eines neuen Studienangebotes aufrufen. Die zweite direkt über das Menu erreichbare Seite zeigt die Liste der vorhandenen Studienangebote. Sie hat zwei Einträge im Menu, einmal um nur die Liste der Studienangebote des Benutzers anzuzeigen, und einmal um die Liste aller Studienangebote anzuzeigen. Beide rufen dieselbe Seite auf, nur mit unterschiedlichen Parametern. Über die Liste der Studienangebote lässt sich die Detailansicht eines konkreten Studienangebotes aufrufen. Von dieser Detailansicht gelangt der Benutzer zu den zwei letzten Seiten im Backend, der Seite zum Hinzufügen eines Elements zu dem Studienangebot, und der Seite zum Bearbeiten eines vorhandenen Elements im Studienangebot. Abbildung 4-1 zeigt die Zusammenhänge zwischen den Seiten, ein schwarzer Pfeil stellt einen Link dar, und ein roter Pfeil entspricht einer automatischen Weiterleitung nach Beendung der aktuellen Seite.

19 Realisierung 19 Navigation im Backend neues Studienangebot anlegen Menu Liste der eigenen Studienangebote Liste aller Studienangebote Detailansicht eines Studienangebotes einzelnes Element bearbeiten dem Studienangebot ein (neues) Element zufügen Seite durch Link erreichbar Seite wechselt nach Beendung automatisch Abbildung 4-1: Navigation im Backend Die Beschränkung auf wenige Seiten ist Resultat der Suche nach einem Konzept, das ü- bersichtlicher ist als für jeden Element-Typ eigene Seiten zum Anzeigen, Hinzufügen und Ändern vorzuhalten. Die neue Aufteilung rührt von der Annahme, dass es ausreicht, Elemente im Kontext von Studienangeboten ändern oder hinzufügen zu können. 4.3 Einfügen eines neuen Studienangebotes Wegen der Komplexität des Datenmodells sind beim Anlegen eines neuen Studienangebotes viele Faktoren zu berücksichtigen. Damit der Benutzer sich nicht mit diesen Faktoren auseinander setzen muss, wurde die Problematik in Kapitel 3.1 behandelt und als Lösung das Konzept des Wizards gewählt. Wie in Kapitel beschrieben führt ein Wizard den Benutzer in Schritten durch die Vorraussetzungen, die zum Anlegen eines neuen

20 Realisierung 20 Studienangebotes nötig sind. (Abbildung 3-2 zeigt alle Schritte des Systems). Bei der Umsetzung des Wizards ist zu entscheiden, wie diese Schritte abgebildet werden Schritte als Folge von Seiten Schritte können als Folge von Seiten umgesetzt werden, jede Seite behandelt einen Schritt. Dies erlaubt, die Daten nach jedem Schritt serverseitig (in PHP) auszuwerten, und dem Benutzer im nächsten Schritt nur Eingabemöglichkeiten anzubieten, die konsistent zu den Daten des aktuellen Schrittes sind. Entsprechen die vom Benutzer übergebenen Daten nicht den Anforderungen, verbleibt der Benutzer im aktuellen Schritt und erhält einen Hinweis mit einer Fehlerbeschreibung. Durch diese Prüfung der Daten zwischen den Schritten ist gewährt, dass der Benutzer den nächsten Schritt erst erreichen kann, wenn die Daten im aktuellen Schritt den Anforderungen entsprechen. Der Ansatz, Schritte als eine Folge von Seiten umzusetzen, ist unkompliziert in PHP implementierbar, weil PHP nach jedem Klick auf weiter die Kontroller erhält. Der Ansatz hat aber einen nicht-technischen Nachteil: der Benutzer weis erst, was er in einem Schritt eintragen muss, wenn er diesen Schritt erreicht. Außerdem sieht der Benutzer nicht mehr, was er in vorigen Schritten eingetragen hat. Bei steigender Anzahl der Seiten könnte der Benutzer deshalb zusehends die Übersicht verlieren. Wie in Kapitel beschrieben, lässt sich die Anzahl der Seiten verringern, indem nicht voneinander abhängige konsekutive Schritte zu einem Schritt gebündelt und auf einer Seite dargestellt werden. Dies verringert die Anzahl der Seiten und steigert damit die Übersicht, die Problematik bleibt jedoch erhalten Schritte als nach Abhängigkeit freigeschaltete Bereiche einer Seite Für den Benutzer übersichtlicher als die Umsetzung von Schritten als Folge von Seiten ist, alle Schritte auf einer Seite anzuzeigen. Der Benutzer sieht zu jedem Zeitpunkt, was er noch eingeben muss und was er bereits eingegeben hat. Während dies für den Benutzer bequem ist, ist die Umsetzung zugleich komplizierter. Es muss weiterhin gewährt sein, dass der Benutzer die Schritte nicht in der falschen Reihenfolge ausfüllen kann. Und es muss weiterhin gewährt sein, dass Schritte mit Abhängigkeiten zu vorigen Schritten nur Eingabemöglichkeiten bieten, die zu den vorigen Eingaben kompatibel sind. Beide Kriterien verlangen, dass die Seite sich im Laufe der Benutzereingaben anpasst. Diese dynamische Anpassung ist mit PHP allein nicht umsetzbar, weshalb zusätzlich Javascript zur Umsetzung verwendet wird.