Designbeschreibung Lehrstuhlverwaltung LV4 Version 1 (4. Release innerhalb der Projektplanung) 1. Allgemeines An einem Lehrstuhl ist es notwendig, dass Angestellte, wissenschaftliche Mitarbeiter, Dozenten, Praktikanten und studentische Hilfskräfte eng kooperieren. Die Kommunikation untereinander findet in der Regel in Meetings und Seminaren durch mündliche Absprachen oder per E-Mail statt. Was fehlt ist eine gemeinsame Verwaltung verschiedener Dokumente, wie die Bücherübersicht, der Veranstaltungskalender, die Hardwareübersicht, der Belegungsplan für lehrstuhlbezogene Seminarräume oder PC-Pools sowie die Literaturliste von Veröffentlichungen des Lehrstuhls. Die Lehrstuhl-Software soll durch ihre Funktionen die Verwaltung eines Lehrstuhls erleichtern und bei allen damit verbundenen Aufgaben für die Nutzer des Systems als Unterstützung dienen, so dass Ressourcen eingespart werden können. Diese Dokumente werden in einem internen Bereich einer Web-Applikation zur Verfügung gestellt. Abhängig von möglichen Aufgaben bezogene Rollen sollen die Mitarbeiter in der Lage sein, diese einzusehen und zu verändern. Im Vordergrund steht dabei eine Containerlösung, die nach und nach mit Verwaltungsaufgaben gefüllt wird. In einer ersten Version sollten oben genannte Aufgaben umgesetzt sein, die dieses Dokument beschreibt. Am Anfang muss sich jeder Benutzer identifizieren, um Zugang zum System zu erhalten und dessen Funktionen nutzen zu können. Folgende Grundfunktionen wurden schon im Prototyp realisiert (statisch): Benutzer können sich einloggen, um Zugriff auf Funktionen zu erhalten. Das Navigieren zwischen den Funktionen ist mittels einer Menüleiste möglich. Jeder Benutzer ist berechtigt, alle News einzusehen. Benutzer können News erstellen. Eigentümer der News können ihre News löschen. Jeder Benutzer ist befähigt, sich aus dem System auszuloggen. Folgende Funktionen sind in der Version 1 der Lehrstuhlverwaltung nutzbar: Musskriterien Bücherliste (alle im Lehrstuhl vorhandenen Bücher, persönliche Listen der Nutzer mit bestimmten Zugriffsrechten/Änderungsrechten) Belegungspläne für Seminarraum und PC-Pools Belegungspläne für Hardware (inkl. Reservierungen) Informationen zu Beschäftigten (Name, Vorname, Bezeichnung, Matrikelnummer bei Studenten, Personalnummer, Kontaktdaten u.a.) Forschungsprojekte (Titel, Inhalt, Dauer, Mitarbeiter) Abwesenheitskalender (Urlaub, Dienstreise, Krankheit u.a.) Veranstaltungskalender Benutzerverwaltung mit Rechtevergabe: Zugriff auf System und dessen Bereiche ist benutzer- und rollenspezifisch und soll über ein Passwort erfolgen Benutzerverwaltung mit Rechtevergabe: Zugriff auf das System erfolgt benutzerabhängig, wobei Schreibrechte nur der Eigentümer eines Dokumentes bzw. eines Eintrags hat. Dieser darf auch nur weitere Eigentümer eintragen. Der Administrator hat alle Rechte ohne Einschränkung. Dokumente können nur dann gelesen wenn sie als publik gekennzeichnet sind oder der Benutzer der jeweilige Eigentümer ist. Suche in allen Dokumenten Wunschkriterien Erweiterbarkeit um zusätzliche Funktionen wie beispielsweise neue Dokumente hinzuzufügen Seite 1 von 1
Bibliotheksverwaltung (wer wann was ausgeliehen und ggf. an wen verliehen hat) Dokumentvorlagen (z. B. Dienstreiseanträge oder Präsentationen) Veröffentlichungsliste (veröffentlicht, akzeptiert, eingereicht, in Bearbeitung) Geburtstagsinformationen Integration in Übungsmanagementsysteme Verwendung einer Datenbank zur Datenverwaltung Graphische Administrationsoberfläche Abgrenzungskriterien Das System ist keine Datenbank, sondern eine xml-datenverwaltung für Dokumente an einem Lehrstuhl. Außerdem dient es nicht zum Informationsaustausch oder zur Interaktion zwischen verschiedenen Lehrstühlen. Da die Lehrstuhlverwaltung über den Web Browser kommuniziert, wird kein festes Graphical User Interface benötigt. Anfragen auf Funktionen werden ausschließlich über die Kommandozeile des Browsers an den Server übermittelt. Produktübersicht Zu Beginn muss sich jeder Benutzer anmelden: Bild 1: Startseite / Login Wenn das System die eingegebenen Logindaten erfolgreich verifiziert hat, wird dem Benutzer das Hauptmenü gezeigt: Seite 2 von 2
Bild 2: Header und Menü Das Menü ermöglicht dem Benutzer eine schnelle und sichere Navigation innerhalb der Lehrstuhl- Verwaltungs-Software. Seine Übersichtlichkeit erhält es durch eine Baumstruktur, welche die Auffindung von bereits erstellten Dokumenten und auch das spätere Hinzufügen von neuen Dokumenten erleichtert. Auf Grund seiner Anordnung am linken Rand ist es unter Beachtung der Übersichtlichkeit fast unbegrenzt erweiterbar. Den Links Main, Suche und Logout kommt eine übergeordnete Rolle im System zu, weshalb sie sich, vom eigentlichen Menü getrennt, im linken oberen Rand befinden. Wenn sich der Benutzer einloggt und sich mit seinem Passwort authentifiziert hat, wird ihm eine Session-ID zugewiesen. Diese merkt sich der Web-Brower des Users in Form eines Cookies, welches er bei jeder Kommunikation mit dem Server sendet. An diesem Cookie, welches die genannte Session- ID beinhaltet erkennt das Servlet des User wider, da es sich auf seiner Seite merkt, welche Session-ID zu welchem User gehört. Da bei der Kommunikation also Cookies verwendet werden, ist es nicht nötig, die Verknüpfungen in den entsprechenden HTML Dokumenten mit der Session-ID anzupassen. Das Hauptmenü wird durch eine entsprechende Schnittstelle im System realisiert, welche in Abhängigkeit vom Benutzer und dessen Rechte auf einzelne Dokumente, eine Menü mit möglichen Verknüpfungen zusammenstellt. Bereits aktive Links in der Version 1: Main: Über diesen Link erreicht man von jedem Dokument aus die Hauptseite der Lehrstuhl- Verwaltungs-Software. Sie beinhaltet die aktuellen News des Tages um dem Benutzer direkt nach seinem Login wichtige Informationen zu übermitteln. News lesen: Hier findet sich eine Übersicht über aktuelle und auch alte News. Jeder Benutzer kann alle geschriebenen News lesen. Seine eigenen News kann der Benutzer über die Links edit und löschen manipulieren. Unter dem Link "edit" besteht die Möglichkeit, den Inhalt der News zu verändern und durch betätigen des OK-Buttons diese zu speichern. Durch anklicken des Links "löschen" wird die betreffende Nachricht gelöscht. Dieser Vorgang lässt sich nicht rückgängig machen. News erstellen: Unter dem Menüpunkt erstellen hat der Benutzer die Möglichkeit selbst News zu erstellen. Dazu trägt er einfach einen Titel in das obere Fenster, und den gewünschten Text in das untere der beiden Fenster ein und bestätigt die Eingabe mit "OK". Dann werden die News für alle sichtbar in die Liste eingetragen. Sollte eines der beiden Fenster nicht ausgefüllt werden, wird die Nachricht nicht gespeichert. Seite 3 von 3
Logout: Jeder Benutzer kann sich aus der Benutzung der Lehrstuhl-Verwaltung ausklinken indem er seine Sitzung über Logout beendet. Um erneut mit dem System arbeiten zu können, muss er sich vorerst wieder über Login anmelden. Sollte der User zu lange nichts machen, wird er, aus Sicherheitsgründen, automatisch ausgeloggt. Noch inaktive Links, die im Verlauf des Projektes vervollständigt werden: Forschung: Dieses Dokument beinhaltet eine Übersicht über die Forschungsprojekte eines Lehrstuhls, um interessierte Benutzer über den Fortschritt der Arbeit und damit in Verbindung stehende wichtige Neuigkeiten informieren zu können. Buchbestand: Dieses Dokument enthält eine Übersicht über den Buchbestand des Lehrstuhls und Informationen über den Status ausgeliehener Bücher. Es kann als Liste nach unterschiedlichen Kriterien (z.b. Autor, Titel usw.) geordnet werden. Weiterhin können dem Bestand neue Bücher hinzugefügt werden. Veranstaltungen: Dieser Kalender zeigt übersichtlich zukünftige Veranstaltungen (bspw. Vorlesungen, Seminar u.a.) um die Benutzer in ihrer Planung zukünftiger Aktivitäten zu unterstützen. Ressourcen: Dieser Link unterteilt sich in einen Plan zu Koordinierung der Raumbelegung und eine Übersicht über alle am Lehrstuhl vorhandene Hardware, um deren Benutzung unter den Beschäftigten eines Lehrstuhls besser abstimmen zu können. Vorlagen: Bei Klick auf den Link "Vorlagen" klappt diese auf und präsentiert weitere Unterpunkte. Diese Unterpunkte sind Dokumenvorlagen. (z. B. Folien für Präsentationen, Briefvorlagen u.a.) und Formularen (z. B. Reiseanträge u.a.). Suche: Dieser Link ermöglicht die Suche in allen Dokumenten über vom Benutzer eingegeben Suchparameter. Nach erfolgreicher Suche wird eine Liste oder in anderer geeigneter Form, abhänging vom Dokument, mit den Ergebnissen angezeigt. 2. Grundsätzliche Designentscheidungen Die Aufgaben unseres System werden von einem Servlet wahrgenommen. Zur Verwaltung der Benutzer oder der Dokumente dienen dem Servlet weitere Klassen, die zum Beispiel die XML- Datenbanken auslesen und bestimmte Grundfunktionen ermöglichen (erstellen, löschen, editieren, lesen, durchsuchen von Dokumenten). Realisierten wir dynamische Datenausgaben im Prototypen noch durch eingesetzte Schlüssel innerhalb der statischen HTML-Dokumente, so nutzen wir jetzt XML und XSL zur dynamischen html- Seitenerstellung. Diese html-seiten werden mit Hilfe eines CSS-Dokumentes einheitlich grafisch dargestellt. Bei unserem System ist es möglich, sich parallel über einen einzelnen Benutzeraccount mehrmals im System anzumelden, da es durch die Verwendung von Cookies und dem von uns verwendeten Datenverkehrkonzept keine Ziel-Adressenkonflikte gibt. Beispiel: gleiche Benutzer melden sich an, haben aber unterschiedliche Cookie-Ids welche vom Servlet verwaltet werden. So bleibt jeder Benutzer auch unter gleichem Namen eindeutig. Ein paar wichtige Klassen: Usermanager authentifiziert einen Benutzer als registriert liest dabei die Datenbank User.xml aus zusätzlich: Login Funktion übernimmt allgemeine Userverwaltung, wie Erstellen und Löschen von Usern XMLDocument ist für die XML Dateiverwaltung zuständig (Speichern, Laden, Verändern, Auslesen und Löschen von Knoten) Seite 4 von 4
hs nimmt die Parameter der URI entgegen und gibt diese an den Core weiter prüft Anmeldung des Benutzers erstellt neue Session zur Weiterverarbeitung löscht gegebenenfalls aktive Session 3. Paket und Klassenstruktur Server Core Dataman Daten Bild 3: Grundlegende Paketstruktur Diese Paketbeziehungen beschreiben die grobe Funktionsweite des Systems. Der Server kommuniziert mit dem Core, der mit Hilfe des Dataman die Daten liest, modifiziert. Das Paket Server ist unter anderem mit dem Servlet für die Kommunikation mit dem User, genauer gesagt dessen Web-Brower zuständig. Es sammelt die eingehenden Daten, wozu die Parameter der URI Benutzername usw. gehören, zusammen und stellt diese dem Paket Core zu. Dieses wiederum nimmt diese Daten entgegen und verarbeitet diese. (Kaffeemühle) Die Informationen und Dokumente, welche der Core zur Bearbeitung benötigt lässt er sich vom Dataman geben. Diese Paket ist nur für die Daten selbst zuständig. Es erfährt nur vom Core welche Operationen es mit den Daten machen soll. Bild 3: Login-Vorgang Seite 5 von 5
Die Benutzer werden vom Server entgegengenommen und mit Hilfe von Dataman identifiziert. Wenn sie registriert sind, werden sie an Core zur weiteren Verarbeitung der Benutzeranweisungen weitergegeben. Dabei funktioniert die Kommunikation über die URI mit mehreren Parametern. Diese werden benötigt, um die entsprechende Ausgabenseite zu laden oder ein Kommando zu übergeben. Das Kommando informiert, welche Funktion des angesprochenen Paketes ausgeführt werden soll. Zum Beispiel wird?aktion=del&doc=news an Dataman gesendet und dient zum Löschen einer News. Alle Benutzerdaten werden in einer XML-Datei gespeichert, um sie persistent zu halten. Eine Speicherung der Benutzer zur Laufzeit ist nicht nötig, da beim Anmeldeprozess eine neue Session erstellt wird und das dazugehörige den Benutzer identifizierende Cookie immer mit gesandt wird. Beim Ausloggen wird das Cookie entfernt, die Session gelöscht (siehe Bild 4) und der Benutzer muss sich neu anmelden. Bild 4: Logout-Vorgang In der kommenden Implementation sind die Verschlüsselung von wichtigen Daten und das kontextspezifische dynamische Laden von neuen Funktionsklassen relevant. Angewandte OO-Konzepte sind: Packet und Klassenkonzepte von Java Dynamische Listen zum Speichern der Parameter in der URI Baumkonzept zum Auslesen der XML Datenverwaltung Seite 6 von 6
Bild : Klassendiagramm Seite 7 von 7
Anhand des Klassendiagramms wird deutlicher, wie das Programm aufgebaut sein wird. Die Klassen sind in drei Packages unterteilt: Server, Core, Dataman. Im Server-Package befinden sich HTTP-Servlet (HS) und eine Session-Klasse. Das http- Servlet koordiniert die Kommunikation mit dem Browser (Endnutzer) und der Applikation. Im Core-Package sind die Klassen zusammengefasst, die Geschäftsprozesse und Funktionen umsetzen. Sie arbeiten auf den Daten, die im Dataman bereitgestellt werden. Die Klasse Door sammelt alle darzustellenden Daten (xml-daten) und verknüpft diese mit grundlegenden Layoutinformationen für html (dazugehörige xsl-dateien). (Das Webdesign wird schließlich mit Hilfe von css-stylesheets durch den Browser vorgenommen.) Die Geschäftsprozesse Dokument hinzufügen, löschen, und editieren werden von der Klasse Modifierer übernommen. Dieser achtet dabei auf die entsprechenden Nutzer-Rechte des jeweiligen Dokumentes und erlaubt nur dann eine Modifikation, wenn der eingeloggte Benutzer auch der Eigentümer des Dokumentes bzw. des jeweiligen Eintrags in diesem ist. Um nicht nicht-modifikative Geschäftsprozesse kümmern sich der Sorter und Sucher, welche für Sortieren und Suchen in Dokumenten verantwortlich sind. Die Klasse Mailer soll Mails versenden können. Die Klasse Illustrator wandelt ein gegebenes Dokument in ein geeignetes XML-Dokument um, damit es dann in Verbindung mit den entsprechenden XSL-Dokumenten in HTML ausgegeben werden kann. Die Klasse Userediter kümmert sich um die Userverwaltung jedes einzelnen Users in dem sie ein Form zu Änderung stellt und die jeweiligen Angaben. Im Dataman-Package werden Klassen gesammelt, die für die Datenhaltung verantwortlich sind. Userman ist für die Datenhaltung der User zuständig. Er prüft Passwörter, legt neue User an, editiert diese oder löscht User. Pack ein ein Datensammlung der Daten die vom Http-Servlet kommen. Es enthält die Parameter der URI, den Usernamen und die Information ob der User ein Admin ist. Die Klasse Statics enthält statische Informationen vom Servlet. Unter anderem die Pfade zu den Daten. (XML-Files, Templats, Logs, usw.) Es bekommt die Informationen von Servlet und bietet dann als statische Instanz jeder anderen Klasse die Möglichkeit seine Dateien zu öffnen und zu schrieben. Logger kümmert sich um das Loggen von Informationen z.b.: Fehler und Userüberwachung durch IP-loggen. Templatloader lädt den Inhalt von einem gegebene Templat und füllt dieses schon aus. XMLDocument ist in Verbindung mit JDOM die Schnittstelle zum XML Verwaltung. Es bearbeitet die Dokumente, liest sie in Bäume ein und bearbeitet die Bäume. Model wird zur Bearbeitung von allgemeinen Dokumenten benötigt. Es liest aus einem XMLDokument den Knotenaufbau. Diese wird benötigt um neue Knoten zu erstellen, in XMLDokumenten, oder XMLDokumente zu bearbeiten oder in diesen zu navigieren. Seite 8 von 8