Select Language:

Architekturschema für VU-Systeme



1. Einleitung

Ein VU-System, das eine Virtuelle Universität implementiert, ist ein komplexes Softwaresystem, das aus verschiedenen Komponenten zusammengesetzt ist. Die Komponenten unterstützen verschiedene Funktionsbereiche der VU, wie z.B. die Bereitstellung von Lehr-/Lern-Material, Informationen aller Art, Arbeitsumgebungen für Lehrende und Lernende, administrative Tätigkeiten (z.B. Einschreiben, Belegen, Organisation von Klausuren und Prüfungen) und Kommunikations- und Kollaborationsdienste für alle beteiligten Gruppen.

In den Universitäten existiert bereits eine Reihe von Systemen, die verschiedene Funktionsbereiche einer VU implementieren. Sie sind entweder von Grund auf neu entwickelt oder Weiterentwicklungen von kommerziellen Produkten und seltener auch rein kommerzielle Produkte. Könnten diese Teillösungen geeignet kombiniert werden, ließen sich weite Bereiche einer VU abdecken. Dem stehen derzeit allerdings technische Inkompatibilität (z.B. fehlende technische Standardisierung der Schnittstellen) und überlappende Funktionalität (fehlende fachliche Abgrenzung der Komponenten) entgegen.

Um ein Zusammenspiel der Teilsysteme bzw. Komponenten zu erreichen, müssen deren Funktionalität und Schnittstellen aufeinander abgestimmt sein. Die konsequente Fortführung dieses Gedankens mündet in ein Architekturschema für VU-Systeme, welches die Entwickler von VU-Komponenten in die Lage versetzt, neue oder verbesserte Komponenten so zu entwickeln, dass sie leicht in bestehende VU-Infrastrukturen integriert werden können. Erste, noch wenig konkrete Überlegungen zu einer derartigen Rahmenarchitektur finden sich z.B. bei F. Milius (Information Management & Consulting 14; 1 (1999). Ein geeignetes Architekturschema für VU-Systeme inklusive Schnittstellenstandards stellt daher eine zentrale technische Voraussetzung für den Erfolg der Open Source-Initiative dar.

2. VU-spezifische Anforderungen an ein Architekturschema

Wir diskutieren nur Anforderungen, die sich aus der VU-Domäne ableiten und nicht ohnehin für jede Softwarearchitektur gelten ("Software Engineering Folklore"). Letztere Anforderungen umfassen z.B. Schichtenarchitektur inkl. Trennung der Benutzungsschnittstelle von der Anwendung, Modularität, Kapselung und Geheimnisprinzip, starke Kohäsion, schwache Kopplung, Skalierbarkeit, Verwendung von Standards usw.

2.1 Kombinierbarkeit von VU-Komponenten

Fachbereiche und Fächer verwenden spezifische Lehrveranstaltungen, Lehr-/Lernszenarien und organisatorische Abläufe, die jeweils von einer oder mehreren VU-Komponenten unterstützt werden müssen. Hieraus leitet sich ein Architekturschema ab, das die einfache Kombinierbarkeit von VU-Komponenten erlaubt, so dass diese leicht zu einer individuellen Arbeitsumgebung zusammengesteckt werden können.

2.2 Adaptierbarkeit der Oberfläche

Fachbereiche und Fächer unterscheiden sich nicht nur in ihren Lehr-/Lernformen, sondern auch bezüglich spezifischer ästhetischer Vorstellungen und Gewohnheiten, die zum Teil in der Fachtradition begründet sind, zum Teil aber auch auf individuelle Präferenzen der Lehrenden zurückgehen. Für die Akzeptanz eines VU-Systems ist es daher wichtig, anpassbare Oberflächen anzubieten, um den unterschiedlichen Vorstellungen der Nutzer mit geringem Aufwand nachkommen zu können. Dabei müssen sich die Oberflächen der eingesetzten VU-Komponenten so einpassen lassen, dass jeweils das einheitliche Erscheinungsbild gewahrt bleibt (corporate identity).

2.3 Austauschbarkeit und Erweiterbarkeit

Der rasante technologische Fortschritt und die damit einhergehende Entwicklung neuer Lehr-/Lernszenarien werden zur Weiterentwicklung bzw. Ersetzung existierender VU-Komponenten und zu zusätzlichen VU-Komponenten für neuartige Funktionsbereiche führen. Derartige Komponentenersetzungen und Systemerweiterungen müssen mit möglichst geringen Auswirkungen auf die existierenden VU-Komponenten durchführbar sein.

2.4 Integration in die IT-Infrastruktur der Hochschule

Zur Arbeitserleichterung für Lehrende und Studierende sowie zur Redundanzvermeidung (und damit zur Konsistenzerhaltung zwecks Reduktion von Fehlerquellen) ist Voraussetzung, dass Daten, die an verschiedenen Stellen benötigt werden, nur einmal erfasst und nur an einer Stelle geändert werden müssen. Da alle wesentlichen Daten über Studierende, Lehrveranstaltungen, Prüfungen usw. bereits in der zentralen IT-Infrastruktur der Hochschulen gehalten werden, stellt die Benutzung dieser zentralen Datenbanken an Stelle einer redundanten lokalen Datenhaltung eine wichtige Anforderung an VU-Komponenten dar.

3. VU-Komponenten

VU-Komponenten verkapseln logisch zusammenhängende Funktionen eines VU-Systems und bieten sie über eine Web-Oberfläche an. VU-Komponenten unterstützen beispielsweise den Übungsbetrieb, die Erstellung und Bearbeitung von Lehrmaterialien, verschiedene Kommunikationsformen (synchron, asynchron, privat, öffentlich,...), Studentensekretariat, Prüfungsamt, Bibliothek und Shop. Eine VU-Komponente implementiert typischerweise in Kooperation mit anderen VU-Komponenten einen Lehr-/Lernbereich, beispielsweise eine komplette Kursumgebung mit Übungen, Kommunikationsangeboten, Klausur usw.

3.1 Architekturschema

Ein typische VU-Komponente weist softwaretechnisch eine klassische Dreischichtenarchitektur auf. Die unterste Schicht bildet die lokale Datenhaltung der Komponente. Darauf aufbauend folgt die eigentliche Anwendungslogik. Die oberste Schicht wird von der Web-Oberfläche der Komponente gebildet, die den Nutzern, insbesondere Studierenden und Dozenten, die Navigation und das Aufrufen der bereitgestellten Funktionen ermöglicht. Abb. 1 zeigt diesen Sachverhalt.

[ Abbildung 1: Architekturschema einer VU-Komponente ]
Abbildung 1: Architekturschema einer VU-Komponente

Die lokale persistente Datenhaltung einer VU-Komponente speichert z.B. persönliche Notizen der Studierenden, bei der Arbeit anfallende Zwischenergebnisse usw., um die persönliche Arbeitsumgebung eines Studierenden jederzeit wieder herstellen zu können. Eine Speicherung in zentralen Datenbanken ist für diese Art von Daten nicht angemessen. Sie würde insbesondere die Änderbarkeit und Austauschbarkeit der Komponenten erschweren. Trotzdem ist die Realisierung der lokalen Datenhaltung aller VU-Komponenten in einem gemeinsamen Datenbanksystem möglich und zur Erleichterung der Administration auch sinnvoll. Die Anbindung erfolgt über den ODBC-Standard bzw. bei Verwendung von Java über JDBC.

Allerdings muss nicht jede VU-Komponente über eine lokale Datenhaltung verfügen. So kann beispielsweise eine Lehrangebotsinformationskomponente alle erforderlichen Daten aus zentralen Datenbanken beschaffen.

3.2 Web-Oberfläche

Die Oberfläche einer VU-Komponente besteht aus einer Menge von untereinander verlinkten Web-Seiten. Üblicherweise sehen Web-Seiten Einstiegspunkte vor, die von anderen VU-Komponenten angesteuert werden können. Typische Beispiele hierfür sind:

Die Adaptierbarkeit der Oberfläche stellt eine technische Herausforderung dar. Für eine genauere Betrachtung ist eine Unterscheidung der Web-Seiten in Individualseiten, die von den Benutzern erstellt werden, und Systemseiten sinnvoll. Systemseiten werden von der VU-Komponente generiert und stellen z.B. Navigationshilfen bereit oder bieten Funktionen an. In erster Linie müssen die von der VU-Komponente generierten Systemseiten anpassbar sein, die Individualseiten sind ohnehin frei gestaltbar. Insgesamt können für eine Web-Seite einer VU-Komponente abhängig vom Anwendungskontext verschiedene Adaptionsvarianten sinnvoll sein:

4. VU-Systeme

Ein VU-System setzt sich aus kooperierenden VU-Komponenten zusammen, die sich auf zentralen Basisdiensten wie z.B. Directory Services, zentralen Datenbanken usw. abstützen. Abb. 2 zeigt schematisch die sich ergebende 4-schichtige Architektur.

[ Abbildung 2: Architekturschema für VU-Systeme ]
Abbildung 2: Architekturschema für VU-Systeme

Zentrale Basisdienste sind nicht einer einzelnen VU-Komponente zuzurechnen, sondern stehen allen VU-Komponenten zur Verfügung. Hierunter fallen in erster Linie zentrale Datenbanken (HIS-Datenbanken) und Directory-Server, die z.B. Daten über Studierende (Stammdaten, Informationen über Belegungen, Studien- und Prüfungsleistungen, Passwörter) und Lehrveranstaltungen enthalten. Darüber hinaus kann man z.B. auch die Infrastruktur für elektronische Bezahlung zu diesen Basisdiensten zählen.

Zur Kommunikation zwischen VU-Komponenten und Basisdiensten werden die Standards LDAP (Directory-Server) und ODBC bzw. JDBC (zentrale Datenbanken) eingesetzt. Gegebenenfalls kann auch CORBA verwendet werden, ein weit verbreiteter Standard, der die Kommunikation zwischen (verteilten) Komponenten regelt und der in allen wichtigen Programmiersprachen implementiert ist. CORBA führt zu einer stärkeren Entkopplung der VU-Komponenten von den Basisdiensten, so dass die Auswirkung einer änderung von Basisdiensten auf die VU-Komponenten verringert wird (z.B. wenn sich eine HIS-Datenbank ändert).

Die direkte Kommunikation zwischen VU-Komponenten stellt eine stärkere Integration als die Benutzung der unterliegenden zentralen Datenbanken dar. Situationen, in denen eine Kommunikation zwischen VU-Komponenten erforderlich wird, sind beispielsweise:

Oberflächenintegration: Eine VU-Komponente liefert die URLs seiner Einstiegspunkte, damit von anderen Komponenten aus dorthin navigiert werden kann, z.B. bei der Integration von VU-Komponenten zu Lehr-/Lernbereichen.

Administrationsunterstützung: Eine VU-Komponente führt Administrationsfunktionen auf Veranlassung einer anderen VU-Komponente aus. Beispielsweise kann man beim Einrichten eines Kurses in der VU-Informatik veranlassen, dass automatisch eine entsprechende Übungsveranstaltung in WebAssign eingerichtet wird.

Komponentenübergreifende Funktionen: Manche Funktionen können nicht von einer Komponente allein ausgeführt werden. Beispiele sind:

Technisch bietet sich CORBA für die Schnittstellen zwischen VU-Komponenten an. Für externe Komponenten, etwa einen Server beim Korrektor zuhause oder einen offline-Reader beim Studierenden, stellt HTTP eine zwar technisch weniger elegante, aber robuste und ebenfalls programmiersprachenunabhängige Alternative dar.

5. Lehr-/Lernbereiche

Typischerweise tragen mehrere VU-Komponenten zur Implementierung eines Lehr-/Lernbereichs bei. So wird ein virtuelles Seminar von VU-Komponenten unterstützt, welche Materialien bereitstellen, ein Diskussionsforum offerieren und Tools anbieten, in denen die Studierenden ihre Beiträge (ggfs. in Gruppenarbeit) erstellen. Die Integration dieser VU-Komponenten zu einer vollständigen und für alle Beteiligten (Studierende und Dozenten) leicht zu bedienenden Seminarumgebung ist eine wichtige Aufgabe, die auf verschiedene Weise realisiert werden kann.

Zum einen kann die integrierte Umgebung (vom Dozenten) individuell von Hand gestaltet werden, eine Möglichkeit, die zwar größtmögliche Flexibilität bietet, aber nur von den wenigsten Dozenten geleistet werden kann. Zum anderen kann die integrierte Umgebung durch Konfiguration einer Umgebungskomponente erzeugt werden.

Umgebungskomponenten sind selbst wieder VU-Komponenten und besitzen wie diese eine Dreischichtenarchitektur. Über die Seiten ihrer Web-Oberfläche steuern sie die Navigation zu den Web-Seiten der integrierten VU-Komponenten. Sie bieten aber auch eigenständige, d.h. von den VU-Komponenten unabhängige Assistenz- und Integrationsfunktionen an:

In der lokalen Datenhaltung kann eine Umgebungskomponente beispielsweise die persönliche Arbeitsumgebung eines Studierenden mit den zuletzt besuchten Seiten aus verschiedenen Komponenten speichern.

Abb. 3 zeigt das verfeinerte Architekturschema für VU-Systeme, das zwischen Umgebungskomponenten und "gewöhnlichen" VU-Komponenten unterscheidet. Man erkennt, wie das Web-Interface einer Umgebungskomponenten zusammen mit den Web-Interfaces der integrierten VU-Komponenten die Web-Schnittstelle des zugehörigen Lehr-/Lernbereichs bildet.

[ Abbildung 3: Architekturschema für Lehr-/Lernbereiche ]
Abbildung 3: Architekturschema für Lehr-/Lernbereiche

6. Funktionaler Zuschnitt von VU-Komponenten

Für das Zusammenspiel von VU-Komponenten spielt neben Architekturschema und Schnittstellenstandards auch der funktionale Zuschnitt von VU-Komponenten eine wichtige Rolle. Außerdem benötigen Anwender Entscheidungshilfen, um geeignete VU-Komponenten für ihren Lehr-/Lernbereich bzw. VU-System auszuwählen.

Um den funktionalen Zuschnitt von VU-Komponenten diskutieren und angebotene VU-Komponenten miteinander vergleichen zu können, ist es sinnvoll, sich zunächst einen Überblick über alle Funktionsbereiche einer virtuellen Universität zu verschaffen. Darauf aufbauend sollen Empfehlungen für den funktionalen Zuschnitt von VU-Komponenten und deren Schnittstellen entwickelt werden.

Nachfolgende Tabelle stellt einen ersten (unvollständigen) Versuch dar, VU-Funktionsbereiche zu identifizieren und zu charakterisieren.

Lehrveranstaltungen
  Beschreibung (aus student. Sicht) Merkmale Beispiel-
komponenten
Lehrmaterial Durcharbeiten des Lehrmaterials Strukturvorgaben, Formate, Freigabeverfahren, Autorenunterstützung VU-Informatik,
ET-Online 1, ILIAS
Übungen Aufgaben lösen Aufgabentypen, Korrekturmöglichkeiten, unterstützte Eingabeformate, Korrektorunterstützung WebAssign, ILIAS
Labor Experimente   "Reale Systeme im virtuellen Labor"
Synchrone, veranstaltungs-
öffentliche Kommunikation
Vorlesung, Vortrag mit Video, mit Audio, mit Folien, mit Aufzeichnung VU-Informatik
Asynchrone, veranstaltungs-
öffentliche Kommunikation
Diskussion   VU-Informatik, ILIAS
private Kommunikation      
Forum für Gruppenarbeit   Zugriffsrechte  
Administration
  Beschreibung (aus student. Sicht) Merkmale Beispiel-
komponenten
Studentensekretariat immatrikulieren, rückmelden, belegen    
Prüfungsamt   für Prüfungen an-/abmelden  
Organisation von (Präsenz-) Veranstaltungen für Seminare, Praktika, Klausuren an-/abmelden    
Raumverwaltung      
Sonstiges
  Beschreibung (aus student. Sicht) Merkmale Beispiel-
komponenten
Bibliothek Literaturecherche, Bücher reservieren, verlängern ...    
Shop Zusatzmaterialien (CDs, Skripte usw.) kaufen    
öffentliche Information Informationen über Lehrangebote, Prüfungs-
ordnungen usw.
   

1: ET-Online » Uni Open Platform