Das Java Remote Funtion Call (JRFC)-Paket von SAP by hcj

VIEWS: 14 PAGES: 27

									Objektorientierte Modellierung für web-basierte Lernsysteme
Seminararbeit Teleseminar “Distance Learning” SS 99 der Universitäten Eichstätt, Freiburg, Karlsruhe und Mannheim

vorgelegt am

Lehrstuhl für Praktische Informatik IV Prof. Dr. W. Effelsberg Universität Mannheim

Institut AIFB Prof. Dr. W. Stucky Universität Karslruhe

im Mai 1999

von Axel Korthaus1, Marc Lakner2 Universität Mannheim Email: korthaus@wifo3.uni-mannheim.de
1

Universität Karlsruhe Email: marclakner@hotmail.com
2

Inhaltsverzeichnis 1. Einleitung................................................................................................................................... 3 2. Objektorientierte Modellierung mit der Unified Modeling Language ...................................... 3 2.1. Motivation einer modellbasierten Vorgehensweise ............................................................ 3 2.2. Grundlagen der Objektorientierung .................................................................................... 5 2.3. Grundlagen der Unified Modeling Language ..................................................................... 6 2.3.1. Modellsichten in der UML ........................................................................................... 7 2.3.2. Diagrammarten in der UML ......................................................................................... 7 2.3.3. Erweiterungsmechanismen in der UML ...................................................................... 9 3. Anforderungen an die objektorientierte Modellierung web-basierter Lernsysteme ................ 10 3.1. Charakteristika web-basierter Lernsysteme ...................................................................... 10 3.1.1. Grundlegende Merkmale und Funktionen.................................................................. 10 3.1.2. Typische Lernszenarien in web-basierten Lernsystemen........................................... 12 3.2. Ableitung resultierender Modellierungsanforderungen .................................................... 13 3.2.1. Anwendungsbereiche für die objektorientierte Modellierung ................................... 13 3.2.2. Spezielle Charakteristika der Modellierung von WWW-Systemen ........................... 14 3.3. Mögliche Lösungsansätze unter Verwendung der UML .................................................. 15 4. Ausgewählte Modellierungsaspekte am Beispiel eines intranetbasierten Lernservers ........... 18 4.1. Konzeption des prototypischen Lernservers bei der Daimler-Chrysler AG ..................... 18 4.1.1 Technische Infrastruktur ................................................................................................. 18 4.1.2 Funktionelle Infrastruktur ............................................................................................... 19 4.2. Auszüge aus dem objektorientierten Systemmodell des Lernservers ............................... 20 5. Zusammenfassung und Ausblick ............................................................................................. 23 6. Literatur ................................................................................................................................... 25

-1-

Abbildungsverzeichnis Abbildung 1: Entstehung der Unified Modeling Language (nach [OMG97]) ................................. 6 Abbildung 2: Klassendiagramm und korrespondierendes Objektdiagramm ................................... 8 Abbildung 3: Einfaches Klassendiagramm einer Universität (angelehnt an [Boo99]) .................... 9 Abbildung 4: Basisarchitektur einer Web-Anwendung (nach [Con99]) ........................................ 10 Abbildung 5: Architektur einer dynamischen Web-Applikation (nach [Con99]).......................... 15 Abbildung 6: Stereotypisierte Klassen mit eigener Darstellung (nach [Con99])........................... 17 Abbildung 7: In Client-Seite enthaltene Formulare senden Daten an Server-Seiten [Con99]....... 17 Abbildung 8: Komponentendiagramm mit Stereotypen für Komponenten ................................... 18 Abbildung 9: Use-Case-Diagramm mit wichtigen Systemfunktionen ........................................... 21 Abbildung 10: Datenbankschema mit der Struktur der Lernmaterialien [Kuc99] ......................... 22 Abbildung 11: Datenbankschema mit Lerntyp- und Rolleninformationen [Kuc99] ..................... 23 Abbildung 12: Einfaches Einsatzdiagramm mit der physischen Hardwaretopologie .................... 23

-2-

1.

Einleitung

Aktuelle Entwicklungen im Bereich moderner Informations- und Kommunikationstechnologien wie Internet, World Wide Web, Multimedia, Computer-Supported Collaborative Work etc. ermöglichen völlig neue Wege des Lehrens und Lernens. Schlagworte wie Computer-BasedLearning, Computer-Based-Training, Edutainment, Multimediales Lernen, Teleteaching, Teletutoring, Wired Education usw. deuten auf die Vielfalt der Möglichkeiten und das gegenwärtig herrschende Interesse an der Thematik hin. Ein Forschungsgebiet, das sich bereits seit einigen Jahren mit der Erforschung eines räumlich und zum Teil auch zeitlich nicht beschränkten Lernkonzepts befaßt, ist das “Distance Learning”. Als eine Art Querschnittswissensgebiet hat es nicht nur informationstechnologische Aspekte zu betrachten, sondern insbesondere auch pädagogische, didaktische, (lern-) psychologische und sozialwissenschaftliche Fragestellungen und Erkenntnisse zu berücksichtigen. Ein wichtiges und sehr aktuelles Teilgebiet des “Distance Learning” ist die Konzeption und Realisierung von verteilten Lernsystemen auf Basis des World Wide Webs (siehe z.B. [EDM96-98]). Hilfreich bei der Konzeption und Implementation jeglicher Systeme, die eine gewisse Grundkomplexität aufweisen, ist die Bildung von Modellen als Basis für die Beherrschung dieser Komplexität, die Abstraktion von unwesentlichen Systemaspekten, die Diskussion der an der Entwicklung beteiligten Personen, die Anforderungsfestlegung sowie die Dokumentation der getroffenen Entwurfsentscheidungen. Dabei hat sich in der Vergangenheit insbesondere das Paradigma der Objektorientierung als besonders geeignete Strukturierungsmethode für die Systemmodellierung erwiesen [Boo99]. In dieser Arbeit beschreiben wir zunächst kurz die allgemeinen Vorteile einer modellbasierten Vorgehensweise, stellen die wichtigsten Konzepte des objektorientierten Ansatzes dar und erläutern die Grundlagen der Unified Modeling Language (UML) (siehe [OMG97], [Rum99]), die als aktueller Industriestandard derzeit die größte Bedeutung unter den objektorientierten Modellierungssprachen besitzt. Aufbauend auf diesen Grundlagen analysieren wir dann die Anforderungen an die objektorientierte Modellierung web-basierter Lernsysteme und zeigen Ansätze zur Adaption der UML an diesen speziellen Modellierungszweck auf. Am Beispiel eines intranetbasierten Lernservers eines großen Unternehmens der Automobilindustrie präsentieren wir schließlich konkrete exemplarische Modellierungsaspekte, die typisch für die Modellierung web-basierter Lernsysteme sind. Den Abschluß der Arbeit bilden eine Zusammenfassung und ein Ausblick auf Möglichkeiten der Codegenerierung für Lernsystemimplementationen auf Basis der objektorientierten Modelle. 2. Objektorientierte Modellierung mit der Unified Modeling Language

2.1. Motivation einer modellbasierten Vorgehensweise Die Entwicklung von Softwaresystemen, die ihren Anforderungen gerecht werden, eine hohe Qualität besitzen und eine stabile Architektur aufweisen, aufgrund derer die Systeme eine hohe Robustheit in bezug auf Veränderungen erhalten, ist ein sehr komplexer Vorgang, bei dem u.a. eine funktionierende Kooperation sehr verschiedener Personengruppen wie z.B. Systementwicklern und Fachexperten (im Fall von Lernsystemen z.B. Psychologen, Pädagogen etc.) erreicht werden muß. Um diesen Vorgang beherrschbar zu machen, wird im Rahmen des „Software Engineerings“ eine ingenieursmäßige Herangehensweise an die Softwareentwicklung -3-

gefordert, wobei i.d.R. Softwarelebenszyklusmodelle mit typischen Phasen bzw. Aktivitäten wie Analyse, Design, Implementation, Test und Wartung zugrundegelegt werden. Diesen Aktivitäten werden bestimmte Teilziele zugeordnet, um gemäß dem Prinzip des „Divide and Conquer“ eine Aufteilung der gesamten Systementwicklung in kleinere Teilprobleme vorzunehmen. Ziel der Systemanalyse ist es beispielsweise, die problemspezifischen und fachlichen Anforderungen an das Produkt festzulegen und in einer sowohl den Auftraggebern und Anwendern/Fachexperten als auch den Systementwicklern verständlichen Notation darzustellen, ohne dabei bereits konkrete Entwicklungsumgebungen, Programmiersprachen, Datenbanken etc. zu berücksichtigen. Letzteres ist Gegenstand der Designphase, in der die Ergebnisse der Analysephase um eben diese Aspekte erweitert werden, um somit die eigentliche Implementation vorzubereiten, die dann schließlich zum einsatzfähigen Produkt führt [Kah98]. Zentraler Bestandteil vor allem der frühen Aktivitäten Analyse und Design ist die Modellierung, die eine bewährte ingenieursmäßige Technik darstellt. Schader und Rundshagen nennen zum Beispiel als eine Aufgabe der Systemanalyse, „... ein vollständiges und konsistentes logisches Ist-Modell des für die Softwareentwicklung relevanten Realweltausschnitts zu erstellen“ ([Sch96], S. 5). Die Modellbildung übernimmt im Rahmen der Systementwicklung eine Vielzahl von Funktionen. So leitet und vereinfacht sie vor allem den Prozeß, das zu entwickelnde System besser zu verstehen und ggf. Verbesserungs- und Wiederverwendungsmöglichkeiten zu identifizieren. Modelle fungieren als Abstraktion und stellen somit eine auf die relevanten Kernaspekte reduzierte Darstellung eines komplexen Systems dar, da ein solches nie in seiner Gesamtheit verstanden werden könnte. Sie dienen dazu, sowohl den Ist- als auch den Sollzustand des Systems zu visualisieren, Struktur und Verhalten des Systems zu spezifizieren, eine Art Bauplan für die Konstruktion des Systems zu liefern und im Entwicklungsprozeß getroffene Entscheidungen zu dokumentieren. Wichtig ist insbesondere auch ihre Funktion als Kommunikationsmedium für die bereits erwähnten an der Entwicklung partizipierenden Parteien wie beispielsweise Anwender, Fachexperten, Analytiker und Systementwickler [Boo99]. Jedes System kann mit Hilfe vieler verschiedener Modelle beschrieben werden, die unterschiedliche Sichten auf das System repräsentieren und jeweils in sich semantisch geschlossene Abstraktionen des Systems darstellen. So sind insbesondere strukturzentrierte Modelle, die die Systemorganisation betonen, und verhaltenszentrierte Modelle, deren Schwerpunkt auf der Systemdynamik liegt, denkbar. In diesem Zusammenhang wird einer der vielen Vorteile des objektorientierten Ansatzes deutlich, der im Gegensatz zu den konventionellen strukturierten Techniken eine natürliche Kapselung zusammengehöriger Struktur- und Verhaltenselemente in Objekten und Klassen ermöglicht (siehe Abschnitt 2.2). Bei diesem Ansatz lassen sich die verschiedenen Teilsichten auf das System zu einer semantischen Einheit zusammenfügen. Darüber hinaus erleichtert ein objektorientierter Ansatz die Modellbildung, da die Abbildung der Realität in Form von Objekten mit bestimmten Eigenschaften und einem bestimmten Verhalten, die in Klassen zusammengefaßt werden können, der menschlichen Wahrnehmung und Kognition näher kommt als herkömmliche Ansätze. Die Möglichkeit, durchgängig durch alle Phasen einer Systementwicklung (von der Analyse über das Design bis hin zur Umsetzung in einer objektorientierten Sprache wie Java) dieselben Abstraktionsprinzipien anwenden zu können, ohne dabei konzeptionelle Brüche überwinden zu müssen, ist ein weiterer Vorteil des objektorientierten Paradigmas. Grady Booch stellt folgende intuitiv einsichtige Behauptung auf: “The more complex your project, the more likely it is that you will fail or that you will build the wrong thing if you do no -4-

modeling at all.” ([Boo99], S. 7) Geht man von der Stichhaltigkeit dieser Aussage aus und akzeptiert man die besondere Mächtigkeit, die dem objektorientierten Paradigma zugeschrieben wird, dann ist die objektorientierte Modellierung sicherlich als ein besonders geeignetes Basisinstrument für die erfolgreiche Entwicklung nichttrivialer Softwaresysteme allgemein und web-basierter Lernsysteme im besonderen anzusehen. 2.2. Grundlagen der Objektorientierung Bei objektorientierter Betrachtung stellen Objekte und ihre Klassen, in denen Objekte mit gleichen Eigenschaften und gleichem Verhalten zusammengefaßt werden können, die zentralen Bausteine von Softwaresystemen dar. Im Gegensatz zur traditionellen Zerlegung von Softwaresystemen in Daten und Funktionen, die zu einer Vielzahl von Problemen geführt hat, verknüpft der objektorientierte Ansatz jeweils die Daten mit den Funktionen, die sie verarbeiten, innerhalb von Klassen und ihren Objekten. Objekte sind Informationsträger, die eine eigene Identität, einen aktuellen Zustand und ein dynamisches Verhalten aufweisen. Sie stellen beispielsweise eine Abstraktion physisch existenter Dinge wie Studenten, Lehrer, Lehrbücher etc. oder auch stärker konzeptionell ausgerichteter Begriffe wie Vorgänge, Rollen, Prozesse, Organisationseinheiten etc. dar. Die Methoden oder Operationen eines Objekts, durch die sein Verhalten definiert wird, kapseln seine Daten, die Attribute, nach außen hin ein. Somit kann nur über die Objektschnittstelle auf die Attribute eines Objekts zugegriffen werden. Die Implementation der Attribute und Methoden bleibt verborgen („Geheimnisprinzip“). Die Objekte im System kommunizieren untereinander durch den Austausch von Nachrichten, wobei der Erhalt einer Nachricht beim Empfängerobjekt zum Ausführen einer seiner Methoden führt. Die Gesamtfunktionalität des Systems entsteht so durch die Kooperation der einzelnen Objekte im System. Ein mächtiges objektorientiertes Prinzip ist die Einführung von Vererbungshierarchien (Generalisierung-Spezialisierung-Strukturen), bei denen speziellere Klassen von allgemeineren Klassen abgeleitet werden und deren Eigenschaften und Verhalten erben. Die abgeleitete Klasse kann darüber hinaus zusätzliche Eigenschaften oder Verhaltensaspekte ergänzen oder das geerbte Verhalten sogar modifizieren. Die Anwendung des Vererbungsprinzips führt zur Verringerung von Redundanzen und ermöglicht die Wiederverwendung bereits existierender Klassen. Ein weiteres mächtiges Konzept in diesem Zusammenhang ist der Polymorphismus. Diese Eigenschaft drückt aus, daß das Versenden derselben Nachricht an Objekte, deren Klassen sich in einer Vererbungshierarchie befinden, zum Aufruf der entsprechenden Methode des jeweils aktuellen Objekts führt, auch wenn der Nachrichtenversand immer über eine Referenz auf die Basisklasse der Hierarchie erfolgt. Um Beziehungen zwischen Objekten einer oder mehrerer Klassen ausdrücken zu können, gibt es das Konzept der Assoziation bzw. Objektverbindung. Ein Spezialfall dieser Art von Beziehung ist die Aggregation (Gesamtheit-Teil-Struktur), bei der ein oder mehrere Objekte in einem oder mehreren anderen Objekten enthalten ist/sind.

-5-

Ein ausführliche Darstellung der Konzepte der Objektorientierung findet sich in zahlreichen Veröffentlichungen zumThema, u.a. in [Neu98],[Kah98],[Sch96]. 2.3. Grundlagen der Unified Modeling Language Anfang der 90er Jahre herrschte ein „Methodenstreit“ unter den Verfechtern verschiedener objektorientierter Methoden. Ca. 50 verschiedene dieser Methoden waren auf dem Markt, zu deren populärsten die Methoden      Booch (Grady Booch) OMT (James Rumbaugh) OOSE/Objectory (Ivar Jacobson) OOA/OOD (Coad/Yourdon) Fusion (Derek Coleman)

zählten. Eine Analyse ergab jedoch, daß die Unterschiede dieser Methoden nur ca. 10% prinzipieller, aber zu ca. 90 % darstellungstechnischer Art waren, so daß eine Konsolidierung sinnvoll und notwendig erschien.

Abbildung 1: Entstehung der Unified Modeling Language (nach [OMG97]) Unter anderem aus diesem Grund (selbstverständlich spielten auch kommerzielle Überlegungen eine Rolle) begannen die Methodiker Grady Booch, James Rumbaugh und später auch Ivar Jacobson, ihre Methoden unter dem Dach der Fa. Rational zusammenzuführen und zu vereinheitlichen. Es entstand zunächst 1995 die Unified Method 0.8, die sich später zur Unified Modeling Language weiterentwickelte (siehe Abbildung 1). Die Änderung der Terminologie wurde damit begründet, daß sich die Arbeit rein auf eine Modellierungssprache, bestehend aus Syntax, Semantik und Notation, beschränkte, während sie die für eine vollständige Methode ebenfalls notwendige Beschreibung eines Vorgehensmodells (siehe z.B. [Jac99], [Kru99]) außer acht ließ. Die Arbeit an der UML stieß auf großes Interesse bei Industrie und Wissenschaft, so daß sich im Rahmen eines öffentlichen Feedbacks immer mehr Partner an der Weiterentwicklung beteiligten. Schließlich wurde die UML in der Version 1.1 (mittlerweile aktuell ist Version 1.3) von der -6-

Object Management Group (OMG), einem der wichtigsten Herstellerkonsortien auf dem Gebiet der Objekttechnologie mit mehr als 700 Mitgliederfirmen, als Standard für objektorientierte Modellierungssprachen verabschiedet und stellt nun die Notation der Wahl zur Darstellung objektorientierter Analyse- und Designmodelle dar. Über ihren Hauptzweck sagt Booch: „Visualizing, specifying, constructing, and documenting object-oriented systems is exactly the purpose of the Unified Modeling Language.“ 2.3.1. Modellsichten in der UML Es wurde bereits kurz darauf hingewiesen, daß die Architektur eines objektorientierten Systems aus mehreren komplementären und ineinandergreifenden Sichten betrachtet werden sollte, um ein gründliches Verständnis zu erzielen. Die UML empfiehlt hierfür eine Use-Case-Sicht (use case view) zur Darstellung der Systemanforderungen, eine Entwurfssicht (design view) zur Beschreibung der Bausteine des Problem- sowie des Lösungsbereichs, eine Prozeßsicht (process view) zur Modellierung der Systemprozesse und Threads, eine Implementationssicht (implementation view) zur Abbildung der physischen Realisierung des Systems, sowie eine Einsatzsicht (deployment view) zur Fokussierung auf Konfigurations- und Verteilungsaspekte. Jede dieser Sichten kann strukturelle wie auch dynamische Gesichtspunkte beinhalten und wird mit Hilfe einer oder mehrerer Diagrammarten der UML (s.u.) ausgedrückt. In ihrer Gesamtheit ergeben die Sichten eine Art Bauplan für das System. 2.3.2. Diagrammarten in der UML Diagramme sind das zentrale Instrument zur Systemmodellierung mit der UML. Sie illustrieren bestimmte Teile oder Aspekte des Systems durch die Anordnung von Modellierungselementen. Jedes Diagramm kann einer (oder mehreren) der eben beschriebenen Systemsichten zugeordnet werden. Die UML enthält folgende Diagrammarten:          Aktivitätsdiagramme, Use-Case-Diagramme, Klassendiagramme, Objektdiagramme, Sequenzdiagramme, Kollaborationsdiagramme, Zustandsdiagramme, Komponentendiagramme und Einsatzdiagramme.

Aktivitätsdiagramme zeigen sequentielle und parallele Flüsse von Aktivitäten im System. Dabei kommen typischerweise drei verschiedene Abstraktionsniveaus zum Einsatz. So können Aktivitätsdiagramme zur Beschreibung von Workflows (Vorgangsmodellierung), von Use Cases (s.u.), sowie für die Spezifikation von Objekt- bzw. Klassenoperationen verwendet werden. Use-Case-Diagramme dienen zur Definition der funktionalen Systemanforderungen und zeigen die wichtigsten Systemfunktionen (Use Cases) sowie externe Akteure (Benutzer, Systeme), die mit dem geplanten System interagieren.

-7-

Klassendiagramme sind die zentrale Diagrammart der meisten objektorientierten Modellierungssprachen. Sie zeigen die statische Klassenstruktur des Systems. Dargestellt werden neben den Klassen und ihren internen Strukturen, bestehend aus Attributen, Operationen etc., auch die strukturellen Beziehungen der Klassen untereinander, wie z.B. Assoziationen und Aggregationen/Kompositionen, Abhängigkeiten, Vererbungsbeziehungen und Gruppierungen zu Paketen, mit denen alle Arten von Modellierungselementen logisch zusammengefaßt werden können. Objektdiagramme zeigen im Gegensatz zu Klassendiagrammen nur Objekte und Instanzen von Beziehungen zu einem bestimmten Zeitpunkt im Systemablauf, d.h., sie bilden sozusagen einen „Schnappschuß“ des Systemzustands zu dem betrachteten Zeitpunkt ab. Abbildung 2 zeigt ein Beispiel für ein Klassendiagramm und einem dazu konsistenten Objektdiagramm.

Abbildung 2: Klassendiagramm und korrespondierendes Objektdiagramm Sequenzdiagramme veranschaulichen den dynamischen Ablauf des Nachrichtenversands zwischen den Objekten, d.h. deren Interaktion. Kollaborationsdiagramme sind Objektdiagramme, die zusätzlich ebenso wie Sequenzdiagramme die dynamischen Nachrichtenflüsse darstellen. Zustandsdiagramme beziehen sich i.d.R. auf einzelne Klassen und beschreiben den Lebenszyklus der Objekte dieser Klasse, d.h. sie spezifizieren mögliche Zustände der Objekte sowie Ereignisse, die zu Zustandsübergängen führen. Komponentendiagramme zeigen die physische Struktur des Codes, wobei sowohl Quellcodekomponenten als auch Binär- und ausführbare Komponenten gemeint sein können. Neben den Komponenten selbst können die Schnittstellen der Komponenten und ihre Abhängigkeiten untereinander explizit dargestellt werden. Einsatzdiagramme illustrieren schließlich die physische Architektur der Hard- und Software im System. Es werden die zum Einsatz kommenden Computer und Geräte (Knoten) und ihre Verbindungen untereinander dargestellt. Innerhalb der Knoten befinden sich ausführbare Komponenten und Objekte, die auf dem betreffenden Knoten ausgeführt werden. Abbildung 3 zeigt abschließend ein Beispiel für ein stark vereinfachtes UML-Klassendiagramm, mit dem der Problembereich einer (möglicherweise virtuellen) Universität modelliert wird. Das Klassendiagramm könnte beispielsweise unmittelbar für die Schemaentwicklung einer -8-

objektorientierten Datenbank, in der die entsprechenden Informationen zu verwalten wären, herangezogen werden.

Abbildung 3: Einfaches Klassendiagramm einer Universität (angelehnt an [Boo99]) 2.3.3. Erweiterungsmechanismen in der UML Eine Besonderheit der UML, die ihr eine enorme Flexibilität verleiht und die auch, wie im folgenden beschrieben, sinnvoll im Rahmen der Modellierung web-basierter Lernsysteme angewandt werden kann, sind ihre eingebauten Erweiterungsmechanismen. Mit Hilfe dieser Mechanismen kann unmittelbar auf das Metamodell der UML, also die eigentliche Sprachdefinition, Einfluß genommen werden, indem beispielsweise die standardmäßig vorgesehene Menge der Modellierungselemente der UML unter Beachtung bestimmter Restriktionen um neue, benutzerdefinierte Elemente mit eigener Notation und Semantik erweitert werden kann. Bei diesen Erweiterungsmechanismen handelt es sich um    Stereotypen, Tagged Values und Zusicherungen.

Mit Hilfe von Stereotypen können auf Basis bestehender Modellierungselemente neue definiert werden, was quasi der Erweiterung des Metamodells um diese neuen Bausteine entspricht. Die Semantik des Basiselements kann dabei erweitert werden, und es ist sogar erlaubt, eine neue Darstellungsform für das erweiterte Modellierungselement zu definieren. Diese Möglichkeiten erlauben die Anpassung der UML an spezifische Modellierungsbedürfnisse oder bestehende Methoden. So ist es u.a. möglich, den Anforderungen an die web-basierte Modellierung durch geschickte Wahl von Stereotypen besonders gerecht zu werden, wie in Abschnitt 3.3 beschrieben. Eine Reihe von Stereotypen ist in der UML bereits vordefiniert. Mit Hilfe von Tagged Values können Modellierungselemente um bestimmte Merkmale erweitert werden, die in Form von Name-Wert-Paaren angegeben werden können (z.B. {Autor = Korthaus}). Neben benutzerdefinierten Tagged Values, die bei Bedarf eingeführt werden können, sind analog zu den Stereotypen bereits einige dieser Merkmale in der UML vordefiniert.

-9-

Der dritte Erweiterungsmechanismus, die Zusicherungen bzw. Nebenbedingungen oder Einschränkungen (engl. constraints), dient dazu, die Semantik eines Modellierungselements beschränkend zu modifizieren (z.B. {Alter >= 18}, um Volljährigkeit zu fordern). Auch hier können wiederum neben den bereits vordefinierten benutzerdefinierte Zusicherungen verwendet werden. 3. Anforderungen an die objektorientierte Modellierung web-basierter Lernsysteme

Nach dieser kurzen Motivation für die modellbasierte Vorgehensweise und der überblicksartigen Darstellung der UML als spezieller objektorientierter Modellierungssprache soll im folgenden nun der Schwerpunkt auf den Modellierungsgegenstand „Web-basiertes Lernsystem“ gelegt werden. Dazu werden grundlegende Merkmale und typische Charakteristika web-basierter Lernsysteme identifiziert, um daraus Anforderungen an deren Modellierung bestimmen zu können. Die Umsetzung der erkannten Modellierungsaufgaben mit Hilfe der UML ist Gegenstand des letzten Abschnitts dieses Kapitels. 3.1. Charakteristika web-basierter Lernsysteme 3.1.1. Grundlegende Merkmale und Funktionen Der Begriff "web-basiertes Lernsystem" kann als Oberbegriff für eine Vielzahl neuer Lernsysteme angesehen werden, deren zentrale Gemeinsamkeit die Nutzung des World Wide Webs als Infrastruktur darstellt, über die der Informationsaustausch und die Kommunikation der teilnehmenden Personen als Basis für die gewünschten Lernprozesse ermöglicht und abgewickelt wird. Typische Merkmale, die die meisten dieser Lernsysteme unabhängig von ihrem konkreten Aufbau im Einzelfall aufweisen, werden im folgenden aufgeführt und konkretisiert:      WWW-basiert Zeit- und Raumunabhängigkeit Interaktivität Flexibilität/Adaptivität Evaluation
Web-Server
http

Client/Browser

verteilt

zeigt an

Web-Seite

Abbildung 4: Basisarchitektur einer Web-Anwendung (nach [Con99]) Unter einem web-basierten System versteht man ein System, das als Informationsdienstmedium vor allem auf das WWW zurückgreift. Dabei entspricht die grundlegende Architektur einer Web Site einer einfachen Client-Server-Struktur und besteht aus den drei Komponenten Web-Server, Netzwerkverbindung und Client-Browser(n) (siehe Abbildung 4). Der Web-Server verteilt

- 10 -

Hypertextseiten mit formatierter Information (HTML-Seiten) an die Klienten, die diese Seiten über ein Netzwerk auf Basis des HTTP-Protokolls anfordern [Con99]. Die Realisierung als web-basiertes System erlaubt raum- und zeitunabhängige Lernszenarien, bei denen Lehrer und Lernende sich weder am gleichen Ort befinden, noch zur selben Zeit anwesend sein müssen. Hinsichtlich des Zeitaspekts unterscheidet man die synchrone und die asynchrone Kommunikation. Wie in Tabelle 1 angedeutet, ist der asynchrone Fall der typischste Anwendungsfall für web-basierte Lernsysteme, aber unter Verwendung entsprechender Technologien (Skripte, Plug-Ins etc.) sind auch synchrone Szenarien realisierbar. Charakteristisch ist jedoch in jedem Fall die Möglichkeit zur zeit- und ortsunabhängigen Komposition, Distribution, Administration und Benutzung von Lehrmaterial auf dem WWW. synchron Kollaboratives Lernen, z.B. gemeinsames und durch einen Tutor geführtes Browsen, wobei Tutor und Schüler an unterschiedlichen Orten zur gleichen Zeit arbeiten. asynchron Zentraler Anwendungsbereich für WBL, z.B. Abruf von hypermedialen Lernunterlagen, die zu einem früheren Zeitpunkt an einem anderen Ort eingepflegt wurden.

Tabelle 1: Unterscheidung asynchroner und synchroner Techniken in WBL Ein web-basiertes Lernsystem sollte unbedingt interaktiv sein, d.h. Reaktionen des Lernenden auf den dargebotenen Lehrstoff sowie Reaktionen des Systems oder eines Lehrers auf die Aktionen des Lernenden sollten ermöglicht werden. Wichtige Technologien, die die Interaktivität unterstützen können, sind u.a. Skriptsprachen wie Java-Script oder dynamisch ladbare und im Client-Browser ausführbare Programme wie Java-Applets, die beispielsweise im Rahmen von dynamisch gestalteten Tests des Lernerfolgs zum Einsatz kommen können, und Email-Komponenten, die den asynchronen Nachrichtenaustausch ermöglichen. Daneben sind im weiteren Sinne Tools wie Chat-Komponenten, Video- und Audiokonferenzkomponenten und Whiteboards optimal geeignet, um auch die synchrone Kommunikation zu ermöglichen. Eine adaptive und flexible Informationsrepräsentation ist eine weitere wichtige Anforderung an web-basierte Lernsysteme, die jedoch bereits über die grundlegenden Anforderungen an die Funktionalität eines solchen Systems hinausgeht. Die Lernsysteme sollten beispielsweise eine individuelle Anpassungsfähigkeit der Wissensdarstellung für die verschiedenen Charakteristika der unterschiedlichen Benutzer bieten. Hierbei sollte es möglich sein, den Nutzer in verschiedene Lerntypen einzuteilen, ihn gemäß seines Vorwissens z.B. als Anfänger, Fortgeschrittenen oder Experten zu kategorisieren, oder ihn gemäß seiner Rolle zu klassifizieren (in einem Unternehmen z.B. Manager, Sachbearbeiter, Fachexperte). Anhand der Klassifikation der Benutzer gemäß ihrer Lerntypen und Rollen ist es nun möglich, auf die speziellen Lern- und Informationsbedürfnisse der jeweiligen Zielgruppe einzugehen und das präsentierte Wissen entsprechend aufzubereiten. Solch ein angepaßter Lernprozeß ist eine wichtige Voraussetzung für effektives Lernen. Um Daten über die Systemnutzung und das Verhalten der Teilnehmer zu erhalten, in erster Linie um deren Lernerfolg zu überprüfen und ein Feedback geben oder dynamisch auf die Leistungsfähigkeit eines Teilnehmers reagieren zu können, muß ein web-basiertes Lernsystem - 11 -

Funktionalität für eine automatische oder durch die Lehrkräfte durchgeführte Evaluation der Systemnutzung durch die Teilnehmer bereitstellen. Insbesondere in Kombination mit der Forderung nach Adaptivität läßt sich hierdurch eine besonders effektive, da individualisierte, Lernunterstützung erreichen. Neben diesen spezifischen Charakteristika und Funktionalitäten muß ein web-basiertes Lernsystem eine Reihe von Grundfunktionalitäten unterstützen, wie zum Beispiel den Bereich der Benutzeradministration mit dem Einrichten und Pflegen verschiedener Benutzerkonten, dem Verwalten benutzerspezifischer Nutzungs- und Evaluationsdaten und der Zugangskontrolle über User IDs und Paßworte. Ebenso sind die Bereiche der Systemadministration und Datenbankverwaltung zu unterstützen. Als weitere Bestandteile web-basierter Lernsysteme, die ebenfalls bei einer funktionalen Betrachtung berücksichtigt werden müssen, identifiziert [Vog99] u.a.   Werkzeuge zur Erzeugung von Lehrmaterialien, wie z.B. HTML-Editoren, Tools für die Erstellung von Animationen/Simulationen und Web-Autorensystemen sowie Werkzeuge zur Kollaborationsunterstützung, wie z.B. E-Mail, Mailing-Listen, Newsgroups und CSCW-Tools wie das BSCW.

3.1.2. Typische Lernszenarien in web-basierten Lernsystemen Auf Basis dieser grundlegenden Eigenschaften und Funktionalitäten web-basierter Lernsysteme lassen sich nun verschiedene Lehr-/Lernszenarien, wie die einfache Distribution und Rezeption von Lehrmaterialien, Tutorate und Übungen, kollaborative Lernformen, Diskussionsplattformen, News/Nachrichtensysteme und explorative Lernformen, realisieren. Lernszenarien beschreiben die unterschiedlichen Anwendungsmöglichkeiten von web-basierten Lernsystemen. In [Kuc99] finden sich u.a. die in Tabelle 2 aufgeführten Lernszenarien, die im folgenden kurz charakterisiet werden sollen. Sie sind keinesfalls überschneidungsfrei und treten in der Praxis häufig als Mischformen auf. Lernszenarien Fernunterricht Task-Forces Medienorientiertes Lernen Bedarfsorientiertes Lernen Wissensmarkt Virtuelle Lernräume Tabelle 2: Übersicht der betrachteten Lernszenarien (nach [Kuc99]) Im Fernunterricht bekommen Teilnehmer elektronisch repräsentierte Lernunterlagen auf Abruf über das WWW zugestellt. Im Verlauf des Kurses absolvieren sie die einzelnen Lerneinheiten, bis sie das Lernziel erreicht haben. Kommunikation zum Kursleiter kann durch E-Mail erleichtert, Kooperation durch Groupware unterstützt werden. (Asynchrones Lernszenario) Task-Forces sind Diskussionsveranstaltungen über festgelegte Lerninhalte zu bestimmten Terminen. Vordefinierte Lernziele liegen nicht vor. Zum Zeitpunkt des Treffs stehen Experten - 12 -

zur Beantwortung der Fragen zur Verfügung. Termine können z.B. durch Gruppenkalender festgelegt werden. (Synchrones Lernszenario) Medienorientiertes Lernen bedeutet das Durcharbeiten hypermedial repräsentierter, zentral gehaltener Lerninhalte. Fragen können an die Lehrer oder Ersteller der Information gemailt bzw. an ein Forum gestellt werden. Jeder Lernende arbeitet für sich die Inhalte ab. (Asynchrones Lernszenario) Beim bedarfsorientierten Lernen muß zunächst eine situationsgetriebene Bildung von Lerngruppen unterstützt werden. Über ein asynchrones Diskussionsforum werden Lernthematiken spezifiziert und nach Abstimmung mit anderen Teilnehmern wird eine Lerngruppe eröffnet. Die Lerngruppen arbeiten nun Lernziele heraus und arbeiten diese ab. Ergebnisse der einzelnen Gruppen werden im Forum hinterlegt. (Asynchrones Lernszenario) Im Wissensmarkt wird die Vermittlung von Lerninhalten als Ergebnis von Angebot der Lehrer und Nachfrage seitens der Lernenden aufgefaßt. Das Produkt "Vermittlung eines Lerninhalts" kann auch über menschliche oder maschinelle Makler übermittelt werden. Lehrer können ihre Veranstaltungsankündigungen in hypermedialen Dokumenten hinterlegen und für eine organisationsinterne, aber öffentlich zugänglichen Suchmaschine registrieren lassen. Fragen an Experten können in Form von E-Mail oder audio-visuell erfolgen. (Asynchrones Lernszenario) Bei virtuellen Lernräumen wird eine Raum-Metapher (2-D oder 3-D) eingesetzt. Lehrer und Lernende sind dabei Agenten, die Lerninhalte werden in der gewählten Metapher visualisiert. Der Eintritt in Lehrveranstaltungen erfolgt über den Browser. Die Teilnehmer können gemeinsame Ressourcen bearbeiten und während der Präsentation über Diskussionsforen Rückfragen stellen. (Synchrones Lernszenario) 3.2. Ableitung resultierender Modellierungsanforderungen Betrachtet man die im letzten Abschnitt dargestellten Merkmale web-basierter Lernsysteme, so wird deutlich, daß es sich hierbei durchaus um komplexe Systeme handeln kann, die aus den eingangs genannten Gründen sorgfältig entworfen und modelliert werden müssen. Welche genauen Modellierungsanforderungen sich nun anhand der vorgestellten Charakteristika ergeben, ist Gegenstand des vorliegenden Abschnitts. 3.2.1. Anwendungsbereiche für die objektorientierte Modellierung Angesichts der Tatsache, daß ein web-basiertes Lernsystem keine monolithische, von Grund auf zu implementierende Softwareapplikation ist, sondern ein System aus zum Teil marktüblichen Komponenten (z.B. WWW-Browser) und ggf. selbst zu erstellenden Bestandteilen (z.B. Serverprogramme) darstellt, soll im folgenden genauer differenziert werden, zu welchen Zwecken und für welche Anwendungsbereiche die objektorientierte Modellierung zum Einsatz kommen kann. So lassen sich zumindest die folgenden Bereiche identifizieren, für die eine Modellierung in Frage kommt und i.d.R. auch sinnvoll ist:   Modellierung einer Funktionsübersicht und Abbildung möglicher Lernszenarien Modellierung der verteilten Gesamtarchitektur des web-basierten Systems - 13 -

  

Modellierung von Programmen und Programmteilen auf Server und Clients Modellierung von Datenbankschemata etc. (z.B. zur Strukturierung des Lernstoffs) Modellierung der Struktur der Web-Seiten (Layout, Vernetzung etc.)

Sollen beispielsweise im Rahmen der Konzeption eines web-basierten Lernsystems zunächst nur grundlegende funktionale Anforderungen an das System festgeschrieben und denkbare Lernszenarien mit den daran beteiligten Teilnehmerrollen dargestellt werden, so muß ein Übersichtsmodell auf einem hohen Abstraktionsniveau erstellt werden können. Um gewünschte Interaktionsformen und Lernabläufe darstellen zu können, muß es möglich sein, dynamische Aspekte im Modell ausdrücken zu können. Um einen Überblick über die verteilte Gesamtarchitektur des Systems gewinnen und die zum Einsatz kommenden Verarbeitungsknoten, ihre Netzwerkverbindungen und die auf den Verarbeitungseinheiten ablaufenden Softwarekomponenten darstellen zu können, müssen neben Modellierungstechniken zur Darstellung der logischen Struktur des Systems auch Techniken für die Modellierung dieser physisch existenten Komponenten bereitgestellt werden. Ein zentraler Punkt ist die Modellierung der Programme und Programmteile auf Server und Clients, die die spezifische Funktionalität des Lernsystems ausmachen und es von einer einfachen, statischen Web-Site unterscheiden. Geht man davon aus, daß auf Client-Seite vor allem handelsübliche WWW-Browser und auf Server-Seite ebensolche Web-Server zum Einsatz kommen, die nicht zu entwickeln und daher auch nicht zu modellieren sind, so bleibt dennoch die Entwicklung der Softwareteile, die dieses Basis-Websystem erst zu einem Lernsystem machen. Auf der Clientseite ist dabei vor allem die Entwicklung von Skripten (z.B. mit VBScript oder JavaScript) und Komponenten (ActiveX oder Java Applets) zu nennen. Auf dem Server können Techniken wie z.B. Java Servlets und CGI-Skripte zum Einsatz kommen, um beispielsweise die Anbindung an eine Datenbank mit den Lehrinhalten zu gewährleisten und HTML-Seiten angepaßt an den jeweiligen Nutzer dynamisch zu generieren. Werden hierbei durchgängig Java-basierte Lösungen verwendet, so entsteht daraus nicht nur der Vorteil der Plattformunabhängigkeit, sondern aufgrund der Tatsache, daß Java eine moderne objektorientierte Sprache ist, kann in diesem Fall besonders von einer vorausgehenden objektorientierten Modellierung profitiert werden. Als Anforderung an die Modellierung ist hier das gesamte Spektrum der im Rahmen der Softwareentwicklung hilfreichen objektorientierten Modellierungstechniken zu fordern. Als vorletzter Punkt wurde die Modellierung von Datenbankschemata aufgeführt. Sollen beispielsweise die zur Verfügung gestellten Lernmaterialien strukturiert und in einer objektorientierten (oder auch in einer relationalen) Datenbank persistent vorgehalten werden, so kann eine entsprechende Modellierung dienlich sein. Hierfür müssen vor allem strukturzentrierte Modellierungstechniken vorhanden sein. Die Modellierung der Web-Seiten mit ihrer Struktur, ihrem Layout und der Verzeigerung untereinander wird in folgendem Unterabschnitt besprochen. 3.2.2. Spezielle Charakteristika der Modellierung von WWW-Systemen

- 14 -

Die bereits beschriebene einfachste dreistufige Architektur einer Web-Applikation reicht i.d.R. für ein web-basiertes Lernsystem nicht aus. Statt dessen sind Web-Seiten mit Hilfe von Skripten und Serverprogrammen dynamisch zur Laufzeit aus Informationen, die in einer Datenbank hinterlegt sind, zu generieren und an die Clients zu schicken. Eine einfache Architektur, die die Verarbeitung einer Web-Seite mit Skript über einen Seiten-Filter ermöglicht, zeigt Abbildung 5.

Datenbank

Web-Server

http

Client/Browser

bezieht sich auf

Seiten-Filter Seite mit Skript
bearbeitet

Abbildung 5: Architektur einer dynamischen Web-Applikation (nach [Con99]) Im Hinblick auf die Modellierung solcher Systeme ist es also wichtig, nicht nur in der Lage zu sein, grundlegende Elemente wie eine Web-Seite abbilden zu können, sondern es müssen auch die verwendeten Skripte und die Umgebungsvariablen, die in ihnen zum Einsatz kommen, modellierbar sein. Dabei ist jedoch darauf zu achten, daß eine Web-Seite sowohl Skripte mit Variab- len haben kann, die auf dem Client zur Ausführung kommen, wie auch solche, die auf dem Server ablaufen. Hier sollte modellierungstechnisch eine saubere Trennung möglich sein. Darüber hinaus sollte auch die grundlegende Struktur der Hypertextdokumente bestehend aus mehreren Web-Seiten, die sich untereinander über Hyperlinks referenzieren, darstellbar sein. Auch das Layout bzw. die Zusammensetzung der Webseiten mit Komponenten, Forms, Framesets usw. sollte modellierbar sein. 3.3. Mögliche Lösungsansätze unter Verwendung der UML Die Mächtigkeit der UML mit ihren zahlreichen Diagrammtypen und Modellierungskonstrukten ermöglicht ihre Anwendung auf einem sehr breiten Feld von Modellierungsaufgaben. Auch die im letzten Abschnitt identifizierten Anforderungen an die Modellierung web-basierter Lernsysteme lassen sich ohne allzu große Schwierigkeiten erfüllen. Beispiele für einige der jeweils vorgeschlagenen Diagrammarten finden sich weiter unten in diesem Abschnitt sowie in Kapitel 4. Die Use-Case-Diagramme sind beispielsweise ein Instrument, das sehr gut für die Modellierung der wichtigsten aggregierten Systemfunktionen sowie der mit dem System interagierenden Akteure herangezogen werden kann. Die einzelnen Use Cases können dann textuell näher spezifiziert oder durch Aktivitäts- und Sequenzdiagramme verfeinert werden, so daß auch bereits die wichtigsten Interaktionsformen verschiedener Lernszenarien abbildbar sind. Anzumerken ist hierbei jedoch, daß weder Use-Case-Diagramme noch Aktivitätsdiagramme, die den klassischen Flowcharts ähneln, wirklich objektorientierter Natur sind, sondern eher einer funktionalen Betrachtung entsprechen. Für den Einstieg in eine Systementwicklung hat sich diese Betrachtungsweise aber bewährt, so daß sie in den objektorientierten Ansatz der UML integriert worden ist. - 15 -

Um die Architektur des Gesamtsystems zu modellieren, sind verschiedene Ansätze denkbar. Mit Hilfe von hoch aggregierten Klassendiagrammen, die überwiegend Pakete, Schnittstellen und Abhängigkeitsbeziehungen enthalten, läßt sich ein Überblick über die logische Struktur des Systems gewinnen. Möchte man physisch existente Komponenten, d.h. Implementationen bzw. Manifestationen von Web-Seiten, Applets, Serverprogramme etc. und deren Abhängigkeiten untereinander modellieren, so bietet die UML Komponentendiagramme als Lösung an. Dabei nimmt man bereits eine Implementations- oder Konfigurationssicht auf das System ein. Ist darüber hinaus abzubilden, wie die hardwaretechnische Systemtopologie aussieht, d.h. welche Verarbeitungsknoten existieren, welche Komponenten jeweils auf ihnen ablaufen und wie sie miteinander verbunden sind, können die für diesen Zweck bestimmten Einsatzdiagramme verwendet werden. Für die Modellierung der Programme und Programmteile auf Server und Client, die die spezifische Funktionalität des web-basierten Lernsystems ausmachen, kann je nach Anwendungszweck das gesamte Spektrum der Modellierungstechniken der UML zum Einsatz kommen. Zentral sind die Klassendiagramme, die die im Programm verwendeten Klassen und Schnittstellen sowie deren strukturelle Beziehungen untereinander abbilden sollen und Sequenz-, Kollaborations- und Zustandsdiagramme für die Spezifikation dynamischer Aspekte, die das Systemverhalten betreffen. Zur Spezifikation der Algorithmik einzelner Methoden können u.U. Aktivitätsdiagramme herangezogen werden. Für die Modellierung von Datenbankschemata zur Strukturierung der in der Datenbank abzulegenden Informationen lassen sich Klassendiagramme verwenden, die ja im weiteren Sinne eine Weiterentwicklung der im Datenbankbereich sehr bekannten ER-Modellierungstechniken darstellen. Bei genauerer Betrachtung der Modellierung von Web-Seiten und den damit zusammenhängenden Variablen, Skripten und Komponenten fällt auf, daß deren logische Abbildung als Objekte mit Attributen und Operationen u.U. zu wenig differenziert ist. Hier können die Erweiterungsmechanismen der UML hilfreich sein, um auf Basis des Modellierungselements „Klasse“ spezifischere Modellierungselemente mit eigenen Symbolen und veränderter Semantik einzuführen. So schlägt beispielsweise [Con99] vor, eine Web-Seite logisch mit Hilfe zweier stereotypisierter Klassen zu modellieren: einer Server-Seite und einer Client-Seite, deren physische Implementation natürlich in derselben Komponente (einer HTMLDatei) zu sehen ist. Damit können alle den Server betreffenden Informationen und Funktionen als Attribute bzw. Operationen einer mit <<server page>> stereotypisierten Klasse modelliert werden, und umgekehrt analog für den Client in einer mit <<client page>> stereotypisierten Klasse. Die Server-Seite kann Beziehungen haben zu anderen Objekten auf dem Server, z.B. zu Geschäftsobjekten in einem dreischichtigen Modell oder Datenbankzugriffsobjekten. Die ClientSeite kann z.B. Beziehungen haben zu Komponenten wie Java Applets oder ActiveX Controls, die auf dem Client ausgeführt werden. Die fundamentale und einseitige Beziehung zwischen Server-Seite und Client-Seite ist in Abbildung 6 dargestellt: die Server-Seite generiert die resultierende Client-Seite.

- 16 -

spKursliste

<<builds>>

cpKursliste

Abbildung 6: Stereotypisierte Klassen mit eigener Darstellung (nach [Con99]) In ähnlicher Weise definiert [Con99] weitere Stereotypen für Klassen, und zwar um auch Forms, Framesets, Targets, Scriplets und XML-Objekte aus logischer Sicht explizit modellieren zu können. Abbildung 7 zeigt ein Klassenmodell mit gemäß den Vorschlägen von [Con99] stereotypisierten Klassen. Über zwei Aggregationsbeziehungen (Symbol: Raute mit Linie) wird ausgedrückt, daß eine Client-Seite der Klasse cpCourseRegistration Formularobjekte der Klassen frmNewStudent und frmStudent enthält, welche die Eingabefelder Last und First bzw. StudID enthalten. Die Formularobjekte unterhalten eine einseitig gerichtete Beziehung zu einer jeweiligen Server-Seite (spProcessNewStudReq bzw. spGetStudentRecord), der sie ihre Daten nach Eingabe übermitteln. Durch die verwendeten Stereotypen läßt sich bereits auf den ersten Blick die jeweilige spezielle Semantik der modellierten Klasse erkennen, und mit Hilfe der strukturellen Beziehungen lassen sich auch Layoutaspekte andeuten (hier: die Client-Seite enthält Formularobjekte).

Abbildung 7: In Client-Seite enthaltene Formulare senden Daten an Server-Seiten [Con99] In der UML selbst sind bereits Standard-Stereotypen für Komponenten vorgesehen, die bei der Modellierung der physischen Implementationssicht eines web-basierten Lernsystems mit Komponenten- und Einsatzdiagrammen hilfreich sein können. Dazu zählen die Stereotypen <<executable>> und <<library>>, die in Abbildung 8 verwendet werden (wobei dort nicht die genannten Strings zum Einsatz kommen, sondern auf eine eigene, stereotypspezifische Symbole zurückgegriffen wird). Web-Pages werden dabei durch mit <<page>> stereotypisierte - 17 -

Komponenten (bzw. hier wieder durch eine spezielles Symbol) dargestellt, und Hyperlinks sind als mit <<hyperlink>> stereotypisierte Abhängigkeitsbeziehungen modelliert. statistik.dll index.html <<hyperlink>> dbzugr.dll test.html test.exe

Abbildung 8: Komponentendiagramm mit Stereotypen für Komponenten 4. Ausgewählte Modellierungsaspekte am Beispiel eines intranetbasierten Lernservers

Im folgenden sollen nun die bisherigen Ausführungen weiter illustriert werden, indem am Beispiel eines intranetbasierten Lernservers der Daimler-Chrysler AG [Kuc99] Modellierungsausschnitte in UML präsentiert werden, wie sie bei einer durchgängig objektorientierten Modellierung entstanden sein könnten. Nur die gezeigten Modelle der Datenbankschemata sind tatsächlich im Praxisprojekt entworfen worden, die anderen Diagramme wurden von den Verfassern ergänzt. (Weitere Beispiele für die objektorientierte Modellierung von Lernsystemen finden sich u.a. in [Bas98], [Her98] und [Nak98]). 4.1. Konzeption des prototypischen Lernservers bei der Daimler-Chrysler AG Ziel des hier beschriebenen Projekts der Daimler-Chrysler AG war die prototypische Realisierung eines adaptiven, intranetbasierten Lernservers für die Repräsentation und Vermittlung firmeninternen Wissens über die objektorientierte Softwareentwicklung. Mitarbeiter sollten unternehmensweit auf die Dokumente mit den Lehrinhalten zugreifen können, wobei das Abrufen der Dokumente auf einfache Weise über einen Web-Browser zu ermöglichen war. Um den unterschiedlichen Informationsbedürfnissen von Softwareentwicklern und Managern Rechnung zu tragen, sollten die Dokumente nur die für den jeweiligen Benutzer relevanten Informationen enthalten. Darüber hinaus waren die persönlichen Lernpräferenzen der einzelnen Benutzer zu berücksichtigen. So ist es denkbar, daß ein Benutzer ein möglichst breites Spektrum an Theorie und Querbezügen fordert, während ein anderer sehr viel effizienter anhand von Anwendungsbeispielen und praktischen Bezügen lernt. Dies impliziert jedoch, daß die Autoren für jeden einzelnen Lerntyp separate Dokumentteile zu einem bestimmten Sachverhalt erstellen müssen. Der Vorteil einer entsprechend angepaßten Informationspräsentation ist jedoch, daß Motivation, Lernbereitschaft und Lernerfolg der Benutzer positiv beeinflußt werden. 4.1.1 Technische Infrastruktur Der Server ist realisiert mit Microsoft Back Office, einer strategischen Unternehmensplattform:   Betriebssystem : Windows NT 4.0 Server HTTP-Web-Server: Internet Information Server 3.0, inklusive der Erweiterung mit - 18 -



Active Server Pages 1.0ß (ASP) Datenbank-Server: SQL-Server 6.5

Um einen dynamischen Aufbau der HTML-Seiten zu ermöglichen, kommen auf dem WebServer ASP-Skripte zum Einsatz. ASP ist keine eigene Skript-Sprache, sondern stellt nur eine Umgebung für verschiedene Skriptsprachen zur Verfügung, wobei im Rahmen der Implementation des Lernservers VBScript gewählt worden ist. Der Lernserver wird auf einem Intel Pentium-II Rechner im Intranet von einem zentralen Standort aus betrieben. 4.1.2 Funktionelle Infrastruktur Ein Teilkonzept besteht in der Abbildung des firmeninternen Wissens in eine zentrale Datenbank unter Berücksichtigung verschiedener Modelle. Die lokal vorliegenden Wissensbestände werden mittels einer Autorenunterstützung in die Datenbank transformiert. Aufbau und Inhalt der Datenbank werden durch eine Reihe von zugrundeliegenden Modellen bestimmt:       Datenbankmodelle umfassen umfangreiche Schemata für Medien-, Benutzer- und Kooperationsobjekte, Lernmodelle integrieren Lerntypen und Benutzerrollen in das Lernsystem, Nutzermodelle enthalten neben den Benutzerprofilen auch Informationen über Gruppen und Gruppenzugehörigkeit für eine zielgerichtete Kooperation, Kooperationsmodelle unterstützen die einzelnen Kooperationsarten wie email, virtueller Hörsaal, Chat und kooperative Navigation, Navigationsmodelle umfassen die Technik adaptiver Links und eine interaktive Navigationshilfe, Statistikmodelle dienen der Auswertung der Server-, Benutzer-, Lern- und Kooperationsstatistiken.

Der Lernserver besteht aus drei fundamentalen Bestandsfaktoren: dem Web-Server, dem ChatServer und dem SQL-Sever. Der Web-Server liefert mittels HTTP auf Anfrage die speziell an den Benutzer angepaßten, dynamisch aus Informationen in der Datenbank generierten WebSeiten. Unabhängig vom Web-Server laufen die Chat-Sitzungen ab. Um einen Chat zu starten, wird im Browser des Benutzers ein Java-Applet geladen, das einen Kontakt zwischen Client und Chat-Server herstellt. Der Chat-Server übernimmt dann die Kommunikation zwischen den Chatpartnern. Web-, Chat- und SQL-Server laufen gemeinsam auf einem Rechner. Die Funktionen des Web-Servers lassen sich folgendermaßen einteilen:     Inhaltsverwaltung: dynamisches Erzeugen von HTML-Seiten mit benutzerspezifischem Lerninhalt, Lese- und Schreibzugriff auf Dokumente und benutzerbezogene Tabellen in der Datenbank Nutzerverwaltung: Erzeugen, Ändern und Löschen von Benutzerprofilen, Lese- und Schreibzugriff auf benutzerbezogene Tabellen in der Datenbank Serververwaltung: Erstellen von benutzer- und themenbezogenen Statistiken über den Lernserver Benutzerhilfen: Online-Hilfe, Navigationshilfe, Suchfunktionen, Lesezeichenverwaltung, Vollbildanzeige - 19 -

 

Lernunterstützung: Annotationen, seitenbezogene Fragen, Übungen und Beispiele Kommunikationsunterstützung: schwarzes Brett, email-Verteiler, kooperative Navigation, Visualisierung eines virtuellen Hörsaals und Anbahnen eines Chats  Autorenunterstützung: Autorenwerkzeug mit Möglichkeit zum Herunterladen auf den Client  Technische Dienste: Verwaltung der Client-Sitzungen, Übertragung der HTML-Seiten mittels HTTP, Interpretation der ASP-Skripte, Zugriffe auf die Datenbank des SQL-Servers mittels ODBC. Die technischen Dienste werden bereits durch den Internet Information Server bereitgestellt. Die Funktionalität des Chat-Servers umfaßt die Kontaktaufnahme und den Austausch schriftlicher Nachrichten in Echtzeit für Chats und Talks. Letztendlich ist der vorgestellte Lernserver ein Prototyp, der viele der beschriebenen Lernszenarien abdecken kann und der alle Merkmale eines web-basierten Lernsystems vereint. Im folgenden Abschnitt werden nun anhand der hier gewonnenen Informationen über die Konzeption dieses Lernservers beispielhafte Modellierungsausschnitte präsentiert, wie sie im Laufe der Entwicklung entstanden sind (Datenbankschemata) bzw. entstanden sein könnten. 4.2. Auszüge aus dem objektorientierten Systemmodell des Lernservers Abbildung 9 zeigt ein denkbares (unvollständiges) Use-Case-Diagramm des Lernservers, mit dem übersichtsartig die zentrale Systemfunktionalität sowie die wichtigsten mit dem System interagierenden Akteure abgebildet werden. Die durch Strichmännchen angedeuteten Akteure haben Beziehungen zu bestimmten Anwendungsfällen, in deren Ablauf sie involviert sind. So ist der Administrator beispielsweise für die Nutzerverwaltung sowie die Server- und DBAdministration zuständig. Die als Ovale modellierten Anwendungsfälle (Use-Cases) müssen noch genauer spezifiziert werden. Dies geschieht zum einen textuell, indem z.B. Vorbedingungen, normaler Ablauf, Nachbedingungen und Ausnahmefälle beschrieben werden, und zum anderen durch Angabe detaillierterer Diagramme wie Aktivitäts- und Sequenzdiagramme. Ebenfalls zu erkennen sind in der Abbildung Beziehungen zwischen Use-Cases, wie die <<extend>>-Beziehung, die andeutet, daß der Use-Case, auf den die Pfeilspitze zeigt, entweder alleine abläuft, oder u.U. durch den Use-Case, bei dem der gestrichelte Pfeil beginnt, erweitert wird: Das Abrufen und Bearbeiten des Lernstoffs kann durchaus isoliert erfolgen; der Prozeß kann aber auch durch Nutzung der Kommunikationsmöglichkeiten unterstützt werden. Die zweite hier verwendete Beziehungsart ist eine Vererbungsbeziehung zwischen dem Use-Case „Kommunikation“ und den spezialisierten Use-Cases „Asynchrone Kommunikation“ und „Synchrone Kommunikation“, die spezielle Ausprägungen des Basis-Use-Cases darstellen.

- 20 -

Abbildung 9: Use-Case-Diagramm mit wichtigen Systemfunktionen Abbildung 10 zeigt ein tatsächlich im Projekt entworfenes Klassendiagramm, das für die Entwicklung eines Datenbankschemas herangezogen wurde. Alle dargestellten Klassen sind in dem Paket „Dokumentbezogene Informationen“ enthalten, das einen logischen Gruppierungsmechanismus zur Verfügung stellt. Anhand der Klassen selbst und den strukturellen Beziehungen zwischen ihnen ist zu erkennen, wie die Lernmaterialen des Lernservers strukturiert sind. So gibt es Vorlesungen, die aus einem oder mehreren Kapiteln bestehen, die wiederum eine oder mehrere Seiten enthalten, welche einen oder mehrere Abschnitte enthalten, die sich schließlich aus einem oder mehreren Inhalten zusammensetzen. Auf Seiten-, Abschnitts- und Inhaltsebene sind jeweils Formatierungs-Templates zugeordnet, die für die Darstellung herangezogen werden. Darüber hinaus werden jeder Seite ein Autor, beliebig viele Bewertungen, beliebig viele Stichworte und beliebig viele Links auf andere Seiten zugeordnet.

- 21 -

Abbildung 10: Datenbankschema mit der Struktur der Lernmaterialien [Kuc99] In Abbildung 11 wird analog zu Abbildung 10 ein im Rahmen des Projekts entworfenes Datenbankschema dargestellt, wobei hier Benutzer, Lerntypen, Rollen sowie deren Beziehungen zu den Lernmaterialien dargestellt sind. Jedem Benutzer werden genau eine Rolle und genau ein Lerntyp zugeordnet. Die Modellierung der Benutzer mit ihren Rollen und Lerntypen ist in einem eigenen Paket namens „Lerntyp und Rolle“ zusammengefaßt. Über Assoziationen zu den dokumentenbezogenen Informationsklassen kann auf Objektebene genau festgelegt werden, welche Informationen für welche Rolle bzw. welchen Lerntyp sichtbar sein sollen. Die strukturellen Beziehungen der Klassen im Paket „Dokumentenbezogene Informationen“ wurden hier aus Gründen der Übersichtlichkeit ausgelassen (vgl. Abbildung 10). Als letztes Beispiel soll noch ein stark vereinfachtes Einsatzdiagramm präsentiert werden, mit dem die Hardwaretopologie des Systems sowie Konfigurationsaspekte abgebildet worden sind. Die als Würfel symbolisierten Verarbeitungsknoten Server und Client sind über ein Netzwerk miteinander verbunden. Bei dem Diagramm handelt es sich um ein Einsatzdiagramm auf Instanzebene (ersichtlich an den unterstrichenen Knotennamen), d.h. es werden konkret vorhandene Rechner modelliert. Über Attribute wird modelliert, daß der Server einen Prozessor der Geschwindigkeit 300 MHz und einen Hauptspeicher der Größe 128 MB besitzt. Da beliebig viele Clients auf den Server zugreifen können, wird aus Vereinfachungsgründen nur ein (namenloser) Client modelliert, der in der rechten oberen Ecke mit einem Sternsymbol versehen ist. Dadurch wird angedeutet, daß beliebig viele Clients dieser Art mit dem Server verbunden sein können.

- 22 -

Abbildung 11: Datenbankschema mit Lerntyp- und Rolleninformationen [Kuc99] Im unteren Abschnitt der Würfelsymbole wird über das Schlüsselwort „Deploys“ angedeutet, welche Softwarekomponenten auf dem jeweiligen Knoten zur Ausführung kommen. Auf den Clients ist dies also zumindest die Komponente für den Web-Browser, und auf dem Server laufen, wie schon erwähnt, der Web-Server, der Chat-Server und der SQL-Server ab. Diese Form der Spezifikation, welche Komponenten auf welchen Knoten ausgeführt werden, ist eine Kurzform. Es ist ebenso möglich, ganze Komponentendiagramme als Teile der Knoten im Einsatzdiagramm aufzunehmen, um detailliertere Informationen abbilden zu können.

Abbildung 12: Einfaches Einsatzdiagramm mit der physischen Hardwaretopologie 5. Zusammenfassung und Ausblick

In der vorliegenden Seminararbeit wurde die Bedeutung der objektorientierten Modellierung für die Entwicklung und Dokumentation web-basierter Lernsysteme untersucht und anhand von Beispielen illustriert. Es wurde gezeigt, daß eine modellbasierte Vorgehensweise eine notwendige Voraussetzung für komplexe Systementwicklungen darstellt. Als besonders mächtiges Modellierungsparadigma wurde die Objektorientierung genannt, mit der eine der menschlichen Kognition entgegenkommende Art der Realweltmodellierung erreicht wird. - 23 -

Aktueller Industriestandard auf dem Gebiet der objektorientierten Modellierungssprachen ist die Unified Modeling Language, deren Grundlagen überblicksartig dargestellt wurden und die für die weitere Untersuchung herangezogen wurde. Anhand einer Analyse der Charakteristika webbasierter Lernsysteme und einer Ableitung resultierender Modellierungsanforderungen wurden mögliche Anwendungsbereiche für die objektorientierte Modellierung bei der Entwicklung webbasierter Lernsysteme aufgezeigt und die den jeweiligen Anforderungen gerecht werdenden UML-Diagrammarten identifziert. Abschließend wurden am Beispiel eines intranetbasierten Lernservers Modellierungsausschnitte präsentiert, die die zuvor erarbeiteten Ergebnisse der Arbeit veranschaulichen. Bewertend bleibt anzumerken, daß die Sinnhaftigkeit der Verwendung einer so umfangreichen und mächtigen Modellierungssprache wie der UML sehr stark von der jeweiligen Zielsetzung abhängt. Kommen beispielsweise nahezu ausschließlich kommerzielle Werkzeuge zum Einsatz, um das web-basierte Lernsystem zu realisieren, so erscheint eine detaillierte Modellierung nicht nur fragwürdig, sondern stellt u.U. einen Zusatzaufwand dar, der keinen nennenswerten Zusatznutzen mit sich bringt. Sind dagegen große Teile der Funktionalität selbst zu entwickeln (z.B. eine spezifische Autorenunterstützungskomponente), so sollte wiederum auf eine Modellierung keinesfalls verzichtet werden. In diesem Zusammenhang kann die Modellierung in naher Zukunft vielleicht zunehmend geeignet sein, die Entwickler von der reinen Programmierarbeit zu entlasten, indem auf den Anwendungsbereich „Web-basierte Lernsysteme“ spezialisierte CASE-Tools zum Einsatz kommen, die auf Basis der objektorientierten Modelle den entsprechenden Programmcode automatisch generieren. Im Sinne einer visuellen Programmierung würden dann spezielle Versionen der UML (u.a. mit den in der Arbeit vorgestellten Stereotypen) zum Einsatz kommen und die textuelle Programmierung weitgehend substituieren.

- 24 -

6.

Literatur

[Bas98] Basque, J., Rocheleau, J., Paquette, G. und Paquin, Ch.: An Object-Oriented Model of a Computer-Enriched High School. Centre de recherche LICEF, Télé-université, Montreal, Canada, EDMEDIA98 (http://ad.informatik.uni-freiburg.de/proceedings) [Boo99] Booch, G., Rumbaugh, J. und Jacobson, I.: The Unified Modeling Language User Guide. Object Technology Series. Addison-Wesley. Reading, Massachusetts u.a. 1999 [Con99] Conallen, J.: Modeling Web Application Design with UML. Conallen, Inc. http://www.conallen.com/ModelingWebApplications.htm [EDM96-98] Online Proceedings of EDMEDIA96, 97, 98. (http://ad.informatik.uni-freiburg.de/ proceedings) [Her98] Hernández-Domínguez, A.: Object modeling of an Adaptable Virtual Class using OMT methodology. Departamento de Sistemas e Computação (DSC), Federal University of Paraíba II, Campina Grande/Paraíba, Brasil, EDMEDIA98 (http://ad.informatik.unifreiburg.de/proceedings) [Jac99] Jacobson, I., Booch, G. und Rumbaugh, J.: The Unified Software Development Process. Object Technology Series. Addison-Wesley. Reading, Massachusetts u.a. 1999 [Kah98] Kahlbrandt, B.: Software-Engineering – Objektorientierte Software-Entwicklung mit der Unified Modeling Language. Springer. Berlin u.a. 1998 [Kru99] Kruchten, Ph.: The Rational Unified Process – An Introduction. Object Technology Series. Addison-Wesley. Reading, Massachusetts u.a. 1999 [Kuc99] Kucharski, O.: Konzept und Realisierung eines intranetbasierten SoftwarekomponentenServers für die objektorientierte Softwareentwicklung in der Daimler-Benz AG. Diplomarbeit. Universität Mannheim, Lehrstuhl für Wirtschaftsinformatik III, Febr. 1999 [Nak98] Nakabayashi, K., Hoshide, T., Seshimo, H. und Fukuhara, Y.: An Object-Oriented Architecture for a Web-based CAI System. NTT Information and Communication Systems Laboratories, Tokyo, Japan, EDMEDIA98 (http://ad.informatik.uni-freiburg.de/proceedings) [Neu98] Neumann, H. A.: Objektorientierte Softwareentwicklung mit der Unified Modeling Language (UML). Hanser. München, Wien. 1998 [OMG97] UML Specification. Object Management Group. OMG Documents ad/97-08-02 bis ad/97-08-09, 19. Nov. 1997 (http://www.omg.org) [Rum99] Rumbaugh, J., Jacobson, I. und Booch, G.: The Unified Modeling Language Reference Manual. Object Technology Series. Addison-Wesley. Reading, Massachusetts u.a. 1999 [Sch96] Schader, M. und Rundshagen, M.: Objektorientierte Systemanalyse – Eine Einführung. 2. Aufl. Springer. Berlin u.a. 1996 [Vog99] Vogel, J.: Konzeptrahmen für Web-basierte Lernsysteme. Seminararbeit. Universität Mannheim, Lehrstuhl für Praktische Informatik IV, April 1999 (http://www.aifb.unikarlsruhe.de/ Lehrangebot/Sommer1999/SeminarDL/seminar2804.ps) - 25 -

- 26 -


								
To top