Entwurf von datenintensiven Webanwendungen

Entwurf von datenintensiven Webanwendungen unter Verwendung von WebML. Umsetzung eines Beispielprojektes "Entwurf eines wissenschaftlichen Online Journals" mit WebML und dem CASE Tool WebRatio.

Freya Weiß

Matrikel: 2207290

Lehrstuhl Internettechnologie: Prof. Dr. Gerd Wagner


Table of Contents

Aufgabenstellung und Vorgehensweise
Aufgabenstellung
Vorgehensweise
Einleitung
Der Entwicklungsprozess für datenintensive Webanwendungen
Allgemein
Am Entwicklungsprozess beteiligte Akteure
Die Phasen des Entwicklungsprozesses
Die Modelle der Web Modeling Language
Allgemeines
Informationsmodell
Hypertextmodell
Content Management Modell
Entwurf und Umsetzung eines wissenschaftlichen Online Journals
Einleitung
Einbindung des Entwicklungsprozesses in WebRatio
Merkmale wissenschaftlicher Journale am Beispiel FQS
Allgemeine Anforderungsbeschreibung des Online Journals
Umsetzung des Datenentwurfs
Umsetzung des Hypertextentwurfs
Umsetzung des Präsentationsentwurfs
Abschließende Bewertung
Notwendigkeit
Integrierbarkeit
Erlernbarkeit
Umsetzbarkeit
Entwicklungsaufwand
Bibliography
A. Eidesstattliche Erklärung
B. Abbildungsverzeichnis
C. Abkürzungsverzeichnis
D. Weitere Modellierungsdokumente

Aufgabenstellung und Vorgehensweise

Aufgabenstellung

Datenintensive Webanwendungen gehören zu den heute am häufigsten vorkommenden Anwendungen im World Wide Web. Durch die immer größer werdende Komplexität, sowie die an solche Anwendungen gestellten vielseitigen Anforderungen, ist es notwendig, eine solche Anwendung mit Hilfe eines Entwicklungsprozesses unter Verwendung einer Beschreibungs- und Modellierungsprache zu entwerfen. Eine speziell für die Anforderungen bei der Entwicklung von datenintensiven Webanwendungen entworfene Modellierungssprache ist die Web Modeling Language WebML. Das Ziel dieser Bachelorarbeit ist die Aufarbeitung der Modellierungsmethode von WebML in Form einer didaktischen Darstellung der wichtigsten Entwurfsmodelle, mit der Einbeziehung des Entwicklungsprozesses für Webanwendungen. Anhand eines beispielhaften Modellierungsprojektes "Entwurf eines wissenschaftlichen Online Journals", sollen die Konzepte von WebML unter Verwendung des CASE Tools WebRatio angewendet, sowie hinsichtlich der Erfahrungen bei der Umsetzung bewertet werden.

Vorgehensweise

Die Einleitung in Kapitel 2 gibt einen kurzen Überblick über die Notwendigkeit einer auf die Bedürfnisse bei der Entwicklung von datenintensiven Webanwendungen angepassten Modellierungsmethodik. Kapitel 3 stellt anschließend den Entwicklungsprozess einer datenintensiven Webanwendung dar. Es werden dabei die für den Entwurf einer Webanwendung wichtigsten Prozessphasen, sowie die vielschichtigen Anwendungsbereiche der an einer Webanwendungsentwicklung beteiligten Mitarbeiter beschrieben.

Nachdem der Entwicklungsprozess einer Webanwendung vorgestellt wurde, werden in Kapitel 4 die Entwurfsmodelle von WebML ausführlich erläutert. Ausschnitte aus den Entwurfsmodellen des modellierten wissenschaftlichen Online Journals dienen dabei als Anwendungsbeispiele, um die Konzepte verständlich zu erklären.

Die Anwendung der Modellierungskonzepte am Beispielprojekt dieser Arbeit erforderte eine langwierige Einarbeitungszeit in die einzelnen Entwurfsmodelle sowie in das CASE Tool WebRatio, das die Phasen des Entwicklungsprozesses einer Webanwendung durch die Möglichkeit des unabhängigen Entwurfs der einzelnen Entwurfsmodelle unterstützt.

Vor der Anwendung der erlernten Modellierungskonzepte muss entsprechend des Entwicklungsprozesses einer Webanwendung eine Anforderungsbeschreibung erstellt werden. In Kapitel 5 wird die Planung und der Entwurf für das wissenschaftliche Online Journal, unter Verwendung von WebML und WebRatio, erläutert. Dabei werden WebRatio, sowie die Erfahrungen mit dieser Software in Bezug auf die Anwendung und die Umsetzung der Entwurfskonzepte von WebML beschrieben.

Abschließend werden in Kapitel 6 die Erfahrungen bei der Umsetzung des Online Journals anhand einiger Kriterien ausgewertet.

Einleitung

Datenintensive Webanwendungen verwalten eine große Menge an Daten und Informationen, die geeignet strukturiert und dem Nutzer angeboten werden müssen. Sie gehören zu den mittlerweile am häufigsten vorkommenden Webanwendungen im Internet. Beispiele datenintensiver Webanwendungen sind Online-Versandhäuser, digitale Bibliotheken oder ähnliche, solche Datenmengen verwaltende, Anwendungen. Das Hauptmerkmal datenintensiver Webanwendungen ist die Verwaltung und der Zugriff auf ein großes Datenangebot, sowie die Bereitstellung komplexer Dienste und Funktionalitäten. Mit zunehmender Komplexität solcher Webanwendungen steigt auch der Bedarf an einer Modellierungssprache für den Entwurf einer datenintensiven Webanwendung und ihrer webspezifischen Besonderheiten wie die Webseitenkomposition und die Navigation zwischen einzelnen Webseiten.

Bei der Modellierung einer datenintensiven Webanwendung greifen die Entwickler auf die Entwurfsmethoden der allgemeinen (objekt-orientierten) Softwaremodellierung zurück. Mit diesen Methoden können die üblichen Anforderungen einer Anwendung erfolgreich modelliert werden. Die konzeptionelle Beschreibung der speziellen Bedürfnisse einer datenintensiven Webanwendung, wie die Webseitentopologie, die inhaltliche Gliederung der Daten und die Navigationsführung, können jedoch nicht oder nur unzureichend abgedeckt werden. Beschreibungen über die Anordnung und Strukturierung der Daten auf Webseiten und die Navigation werden nicht in einem Modell festgehalten. Entwickler von Webanwendungen greifen hier für die Beschreibung des Frontend der Anwendung oft zu weiteren schriftlichen Ausführungen oder Zeichnungen zurück. Anhand der entworfenen Datenstruktur, einer Auflistung von ausgearbeiteten funktionalen Anforderungen und weiteren textuellen Beschreibungen bezüglich der Umsetzung, wird die Webanwendung programmiert. Genau an diesem Punkt greift das Ziel der Modellierungsmethodik von WebML.

WebML ist eine XML-basierte Beschreibungssprache und stellt konzeptionelle Modelle bereit, die genau diese webspezifischen Eigenschaften wie Struktur, Komposition, Navigation und Personalisierung einer datenintensiven Webanwendung beschreiben. WebML ist im Rahmen des W3I3 Projektes (Web-Based Intelligent Information Infrastructures) von 1998-2000 entstanden. Dieses Projekt war Teil des Fourth Framework Programs und wurde durch die EU finanziert. ([WebML] S.2)

WebML ermöglicht eine plattformunabhängige Modellierung von komplexen Webanwendungen auf einer hohen Abstraktionsebene. Sie orientiert sich dabei an den bewährten konzeptuellen Modellierungssprachen der Softwareentwicklung, wie dem Entity-Relationship Modell oder UML (Unified Modeling Language) und kann so in den bisherigen Entwicklungsprozess eingebaut werden. Die modellbasierte Entwicklung einer datenintensiven Webanwendung mit WebML wird durch einen erweiterten Entwicklungsprozess unterstützt, der in verschiedenen Phasen die unterschiedlichen Modelle der WebML hervorbringt.

WebML und die begleitenden Entwurfsmethoden werden zusätzlich durch ein kommerzielles Webentwicklungstool namens WebRatio Site Development Studio, kurz WebRatio, unterstützt. WebRatio wurde von dem noch jungen Unternehmen Web Models entwickelt. Das Tool deckt den gesamten Entwicklungsprozess ab, indem die einzelnen Modelle seperat entworfen werden können. Ausserdem ermöglicht WebRatio die automatische Generierung des Programmcodes durch die Analyse der Modellstruktur und beschleunigt so den gesamten Entwicklungsprozess.

Im Verlaufe dieser Arbeit werden die Modellierungskonzepte von WebML erläutert und an einem Beispielprojekt angewendet. Abschließend erfolgt eine Einschätzung von WebML in Verbindung mit WebRatio anhand einiger Kriterien.

Der Entwicklungsprozess für datenintensive Webanwendungen

Allgemein

Die Modelle von WebML sind in einem, der Modellierungsmethodik von WebML angepassten, Entwicklungsprozess eingebettet. Der Entwicklungsprozess für datenintensive Webanwendungen stellt keinen neuen Entwicklungszyklus für die Modellierung einer Software dar, sondern orientiert sich an bereits etablierten Entwicklungsprozessen aus dem Bereich der konventionellen Softwaremodellierung ([Balzert00] S.51). In Abbildung 1 sind die Phasen des Entwicklungsprozesses für datenintensive Webanwendungen und ihr Zusammenwirken, die Einbindung der wichtigsten Entwurfsmodelle von WebML, sowie die am Entwicklungsprozess beteiligten Akteure gemeinsam dargestellt.

Figure 1. Phasen des Entwicklungsprozesses einer Webanwendung und Bezug zu den Modellen der WebML.

Phasen des Entwicklungsprozesses einer Webanwendung und Bezug zu den Modellen der WebML.

Der Entwicklungsprozess teilt sich in 7 Prozessphasen auf, die schrittweise und iterativ angewendet werden. Die Phasen Anforderungsanalyse, Datenentwurf und Hypertextentwurf befassen sich mit der Analyse und dem Entwurf einer Webanwendung, wobei in jeder Phase auf das Ergebnis der ihr vorausgegangenen Phase zurückgegriffen wird. Ausgehend von festgesetzten Unternehmensanforderungen beginnt der Entwicklungsprozess mit der Phase der Anforderungsanalyse. Ziel dieser Phase ist die formale Beschreibung der zu entwickelnden Webanwendung, das heisst die Identifizierung der benötigten Nutzer und Nutzergruppen, die Festlegung der Funktionen, die durch die Anwendung angeboten werden, sowie die Ausarbeitung der Datenobjekte, die den Inhalt der Anwendung darstellen. Während der Phase des Datenentwurfs wird ausgehend von der zuvor definierten Anforderungsbeschreibung die eigentliche Datenstruktur der Anwendung in Form eines Modells erarbeitet.

In der Literatur ([CeriFrat03], [WebML]) wird der Begriff Datenmodell bzw. Strukturmodell verwendet, denn es handelt sich um die strukturierte Darstellung der Daten, die durch die Anwendung verwaltet werden. Da aber nicht ausschließlich die Daten dargestellt werden, sondern auch allgemeine Informationen aus dem Modell gewonnen werden können (Zugriffsrechte für verschiedene Nutzergruppen, Objekteigentum oder Navigationsbeziehungen), ist hier der Begriff des Informationsmodells aussagekräftiger und wird im weiteren Verlauf dieser Arbeit anstelle von Datenmodell verwendet.

Bei der Modellierung des Informationsmodells wird immer wieder auf die Phase der Anforderungsanalyse zurückgegriffen und es werden gegebenenfalls Veränderungen oder Erweiterungen vorgenommen. Das Informationsmodell dient als Grundlage für die weitere Entwurfsmodellierung. Ausgehend vom Informationsmodell wird in der Phase des Hypertextentwurfs das Hypertextmodell entwickelt. Hier wird die Webseitentopologie, die Datenstruktur und die Seitennavigation festgelegt, das heisst welche Daten in geeigneter Form dem Nutzer präsentiert werden und wie der Zugriff auf diese Daten erfolgt. Es wird damit die Struktur des gewünschten Hypertextes festgelegt.

Die Phasen Datenentwurf und Hypertextentwurf hängen stark voneinander ab, denn nur die Datenobjekte, die im Informationsmodell vorhanden sind, können im Hypertextmodell umgesetzt werden. Werden weitere Datenobjekte bei der Hypertextmodellierung benötigt, wird das Informationsmodell entsprechend erweitert und anschließend das Hypertextmodell angepasst. Die Abhängigkeiten und das Zusammenspiel der einzelnen Prozessphasen werden ebenfalls in Abbildung 1 gezeigt. Die Entwurfsphasen Datenentwurf und Hypertextentwurf werden weitestgehend durch das Informationsmodell und das Hypertextmodell unterstützt. Für die Modellierung von weiteren webanwendungsspezifischen Aspekten, wie dem Content Management, wird das Hypertextmodell durch das Content Management Modell entsprechend erweitert.

Die Phasen Architekturentwurf, Implementierung, Test und Bewertung und Entwicklung und Pflege befassen sich mit der technischen Umsetzung und der Wartung der Anwendung, basierend auf den zuvor entstandenen Entwurfsmodellen. Die einzelnen Phasen für die Analyse und den Entwurf der Anwendung und damit die entstehenden Entwurfsmodelle werden ständig wiederholt bzw. verfeinert, bis ein den Unternehmensanforderungen entsprechendes Ergebnis vorliegt. Nach jedem Durchlauf des kompletten Entwicklungsprozesses entsteht eine Zwischenversion der Anwendung. Diese Version der Anwendung wird getestet und bewertet, und entsprechend der Ergebnisse und auftretenden Probleme verändert bzw. erweitert. ([CeriFrat03] S.196 f. )

In den folgenden Kapiteln werden die am Entwicklungsprozess beteiligten Akteure, sowie die einzelnen Phasen des Entwicklungsprozesses detaillierter erläutert.

Am Entwicklungsprozess beteiligte Akteure

Die Aufteilung der Phasen des Entwicklungsprozesses entspricht der eigentlichen Arbeitsteilung zwischen den beteiligten Entwicklern, die dadurch weitestgehend unabhängig voneinander Teilaspekte der Anwendung entwerfen können. In ([CeriFrat03] S.195f.) werden folgende Akteure bei der Entwicklung von Webanwendungen unterschieden:

Der Anwendungsanalytiker sammelt die Unternehmensanforderungen, abgeleitet aus den langfristigen Zielen des Unternehmens. Im Hinblick auf die zu entwickelnde Anwendung leitet er daraus die Beschreibung der konkreten Anwendungsanforderungen ab. Er ist somit verantwortlich für die Festsetzung der zu erfüllenden Anforderungskriterien, die als Grundlage für die Modellierung der weiteren Modelle dienen. Das Arbeitsergebnis eines Anwendungsanalytikers ist die Anforderungsbeschreibung.

Der Datenarchitekt befasst sich mit dem Prozess des Datenentwurfs und konzentriert sich auf den Bereich der Anforderungsbeschreibung, der die Daten (Datenobjekte) der Anwendung beschreibt. In der Phase des Datenentwurfs entwickelt er daraus ein konzeptuelles Informationsmodell.

Der Anwendungsarchitekt konzentriert sich auf den Bereich der Anwendungsbeschreibung, der sich mit den herausgearbeiteten Diensten und Funktionen der Anwendung befasst. Er entwirft in der Phase des Hypertextentwurfs den Anwendungs-Hypertext, indem er Sichten auf den Hypertext entsprechend verschiedener Nutzergruppen, und damit die Komposition und Verbindung einzelner Seiten und Datenobjekte definiert. Grundlage hierfür ist das zuvor entworfene Informationsmodell.

Der Grafikdesigner entwirft das Layout der Seiten und orientiert sich dabei an den Unternehmensanforderungen, die sich mit der visuellen Identität und den Kommunikationsstandards des Unternehmens beschäftigen (Corporate Identity).

Der (Anwendungs)Entwickler und (Seiten)Administrator ist für den Architekturentwurf, die Implementierung und die Seitenentwicklung verantwortlich. Er legt somit die Hardware, Software und Netzwerkkomponenten fest und implementiert den Hypertext basierend auf dem Daten- und Hypertextentwurf. Die technische Umsetzung der Webanwendung wird durch WebRatio automatisiert und ermöglicht somit eine schnelle Entwicklung eines Prototyps der gewünschten Webanwendung.

Zum Testen und Bewerten der aktuellen Version einer Anwendung werden üblicherweise weitere Spezialisten hinzugezogen, die die Funktionstüchtigkeit der Anwendung hinsichtlich der gestellten Anforderungen prüfen. Dabei wird wieder auf die, während der Anforderungsanalyse entstandene, Anforderungsbeschreibung zurückgegriffen. Hierdurch wird nochmals der starke Zusammenhang der einzelnen Phasen speziell im Bereich Analyse und Entwurf verdeutlicht. Eine in der Hierarchie des Entwicklungsprozesses weiter unten liegende Phase benutzt den Entwurf der darüber liegenden Phase als Grundlage für die Entwicklung weiterer Teilaspekte der Webanwendung, bis am Ende ein Prototyp fertiggestellt ist. Die Entwickler entwerfen zwar unabhängig voneinander die einzelnen Modelle und somit die Teilaspekte der Anwendung, sind aber dennoch grundlegend voneinander abhängig, da jede Phase wesentliche Ergebnisse für eine weitere Phase liefert.

Die Phasen des Entwicklungsprozesses

Phase 1 - Anforderungsanalyse

Der Entwicklungsprozess einer datenintensiven Webanwendung beginnt mit der Ausarbeitung einer Anforderungsbeschreibung. In der Phase der Anforderungsanalyse werden die wichtigsten Informationen über den Anwendungsbereich und die geforderten Funktionen einer Anwendung zusammengefasst und durch entsprechende Beschreibungen formalisiert. Diese Beschreibungen dienen den Entwicklern als Grundlage für die zu entwickelnden Modelle, um zu verstehen, welche Anforderungen die Webanwendung erfüllen muss. Ausserdem dienen sie zur Kontrolle, ob die in der Phase des Testens und Bewertens befindliche Version der Webanwendung die gewünschten Anforderungen und Dienste erfüllt. Damit wird die Wichtigkeit dieser Phase bei der Entwicklung einer Webanwendung deutlich.

Die zu definierende Anforderungsbeschreibung bildet die Basis für alle weiteren Phasen des Entwicklungsprozesses und demnach für deren zu entwickelnden Modelle der WebML. Das Ziel einer Anforderungsbeschreibung ist es, am Ende ein umfassendes Bild der zu entwickelnden Anwendung zu erhalten. Im Bereich der Softwaremodellierung ist es üblich in der Planungssphase ein Pflichtenheft auszuarbeiten, welches eine detaillierte verbale Beschreibung der Anforderungen an ein neues Produkt enthält ([Balzert00] S.111 f.). In Anlehnung daran wird in ([CeriFrat03] S.204 ff.) für die Sammlung der notwendigen Anforderungen einer Webanwendung, das Vorgehen nach einer strukturierten „Checkliste“ empfohlen. Diese ist jedoch nur als ein möglicher Ablauf aufzufassen. Jeder Anwendungsanalytiker wird eigene Methoden besitzen, nach denen er schrittweise die Anforderungen einer Anwendung herausarbeitet. Eine Anforderungsanalyse sollte je nach Komplexität der Anwendung als Endergebnis folgende Aspekte beinhalten:

1. Definition der Nutzer oder Nutzergruppen

Dies umfasst eine Auflistung der vorhandenen Nutzer bzw. Nutzergruppen mit einer allgemeinen Beschreibung der gegenseitig abgrenzenden Zugriffsrechte auf die Daten der Anwendung. Für jede Nutzergruppe wird typischerweise eine eigene Sicht auf die Anwendungsdaten definiert. Jede Sicht stellt die Inhalte und Funktionen bereit, die zur Erfüllung der Bedürfnisse der Nutzer dieser Gruppe dienen. Diese Informationen sind vor allem für den Entwurf des Informationsmodells sowie des Hypertextmodells von Bedeutung.

2. Beschreibung der funktionalen Anforderungen

Die wichtigsten funktionalen Anforderungen zur Beschreibung der angebotenen Funktionen bzw. zur Darstellung der Interaktionen der Nutzergruppen mit der Anwendung, sollten zusätzlich zur textuellen Beschreibung in Form von einfachen Use-Case-Diagrammen dargestellt werden. Hier ist es von Vorteil, ausgehend von den abgegrenzten Nutzergruppen, die funktionalen Beschreibungen vorzunehmen, denn so behält man eine klare Struktur bei der Definition der einzelnen Funktionen und der daraus abzuleitenden Sichten.

3. Datenobjektverzeichnis

Ein Datenobjektverzeichnis beinhaltet die Beschreibung der Datenobjekte, die durch die Anwendung verwaltet werden. Die wichtigsten Datenobjekte, die sogenannten Kernobjekte, bilden in der Phase des Datenentwurfs die Kernkonzepte bei der Modellierung des Informationsmodells. Diese Kernobjekte werden durch die Anwendung dem Nutzer dargestellt und durch interne Systemnutzer wie Administratoren oder Mitarbeiter verwaltet.

4. Einfache Sicht-Beschreibungen

Einfache Beschreibungen der Sichten, die dem Nutzer erlauben die in den Use-Cases definierten Funktionen auszuführen, dienen dazu, eine allgemeine Vorstellung von der Anwendung hinsichtlich der späteren Umsetzung zu bekommen. Hier wird in einfacher Form beschrieben welche Daten dem Nutzer zugänglich sind, und vor allem wie diese auf den einzelnen Webseiten angeordnet sind.

5. Beschreibung der nichtfunktionalen Anforderungen

Weitere mögliche Inhalte einer Anforderungsbeschreibung sind die wichtigsten nichtfunktionalen Anforderungen der Anwendung, die nicht den Anwendungsfunktionen zugeordnet werden können. Dabei werden folgende nichtfunktionalen Anforderungen unterschieden([CeriFrat03] S.208 f.):

  • Benutzerfreundlichkeit (Usability)

    Benutzerfreundlichkeit wird durch verschiedene Faktoren bestimmt. Dazu gehört die einfache Erlernbarkeit der Benutzeroberfläche, die Einhaltung bekannter Standards zur Benutzerführung wie Menüs, Links oder Buttons, eine in sich stimmige Nutzung der Interaktionsobjekte über die verschiedenen Anwendungsoberflächen hinweg, sowie die Unterstützung des Nutzers durch Orientierungshilfen.

  • Leistungsmerkmale (Performance)

    Leistungsmerkmale beschreiben die Fähigkeit, mit der eine Anwendung zur Verfügung stehende Ressourcen ausnutzt. Der kritischste Faktor im Bereich der Webentwicklung ist die Zeit. Die Leistung einer Anwendung wird im Bereich des Webs anhand des Datendurchsatzes, das heisst anhand der Anzahl der Anfragen, die durch den Server erfüllt werden können, und der Antwortzeit bis zur Erfüllung einer Anfrage gemessen.

  • Erreichbarkeit (Availability)

    Ziel sollte es sein, ein hohes Maß an Erreichbarkeit der Anwendung zu erfüllen. Mit dem Begriff der Erreichbarkeit wird die tolerierte Häufigkeit von Ausfällen und Fehlern in der Anwendung beschrieben. Aufgrund oftmals vorhandener Beschränkungen an Hilfs- und Finanzmitteln muss ein Kompromiss zwischen höchster Erreichbarkeit und Fehlerrisiko gefunden werden.

  • Anpassbarkeit (Scalability)

    Damit wird die Fähigkeit einer Anwendung beschrieben, ihre Leistungsfähigkeit aufgrund einer steigenden Anzahl von Anfragen anzupassen. Skalierbarkeit wird durch die Vervielfältigung von Architekturelementen wie Server oder Netzwerkverbindungen erreicht, so dass ein größerer Datendurchsatz möglich ist.

  • Sicherheit (Security)

    Der Sicherheitsaspekt ist einer der wichtigsten zu erfüllenden Faktoren in komplexen Webanwendungen. Zu den Sicherheitsaspekten gehören Datenschutz, Authentifizierung von Nutzern und die Sicherung des Informationsflusses zwischen Nutzern und der Anwendung.

6. Gestaltungsrichtlinien

Die Definition von Gestaltungsrichtlinien für das Layout der zu entwickelnden Webanwendung gehört ebenso zu einer vollständigen Anforderungsbeschreibung, sofern ein Unternehmen spezielle Vorstellung besitzt oder ein spezielles Layout einhalten muss.

Je nach Komplexität und Größe der zu entwickelnden Webanwendung können einzelne Aspekte der Anforderungsbeschreibung wie die Beschreibung nichtfunktionaler Anforderungen vernachlässigt werden. ([CeriFrat03] S.203-248)

Phase 2 - Datenentwurf

Im folgenden Abschnitt wird anhand ([CeriFrat03] S.249-272) die Phase des Datenentwurfs näher erläutert. Die Phase des Datenentwurfs schließt direkt an die Phase der Anforderungsanalyse an. Eine Webanwendung hat das Ziel, bestimmte Daten und Informationen in strukturierter Art und Weise zur Verfügung zu stellen. In der Phase der Anforderungsanalyse werden, wie bereits beschrieben, die wichtigsten Datenobjekte herausgearbeitet und deren Beziehungen untereinander formuliert. Diese Datenobjekte bilden das Kernkonzept für den Entwurf des Informationsmodells. Der sogenannte Datenarchitekt entwirft ausgehend von den identifizierten Datenobjekten und den weiteren ihm gegebenen Informationen ein zusammenhängendes Informationsmodell und damit die Datenstruktur der Anwendung.

Datenmodellierung ist eine aus der Softwaremodellierung bekannte, weit verbreitete und gut etablierte Disziplin. Die Web Modeling Language orientiert sich zum Entwurf der Datenstruktur an den Ansätzen bekannter Entwurfsmodelle wie dem Entity Relationship Modell (ER-Modell) und UML-Klassendiagrammen und erweitert zusätzlich die Entwurfmodellierung entsprechend der Besonderheiten von Webanwendungen. Dazu gehört die Klassifizierung zusätzlicher Objekte für hierarchischen Zugriff auf bestimmte Datenobjekte, die Möglichkeit der Personalisierung von Daten sowie die Verbindung von Kernobjekten durch Beziehungen, zur Darstellung von Navigation. Die unterschiedlichen Rollen dieser Objekte werden genutzt, um eine bestimmte Gliederung bei der Modellierung des Informationsmodells aufzustellen. Es werden hierbei 4 Objekttypen unterschieden, die wiederum 4 Typen von Subschemata hervorbringen und zusammen das Informationsmodell bilden:

1. Kernobjekte und daraus resultierende Kernsubschemata

Die Kernobjekte sind die wichtigsten Informationseinheiten, die während der Phase der Anforderungsanalyse herausgearbeitet werden. Bei Kernobjekten handelt es sich um die Datenobjekte, die den externen Nutzern der Anwendung dargeboten werden, oder die durch interne Nutzer mit entsprechenden administrativen Rechten verwaltet werden. Die Kernobjekte bilden somit das Grundgerüst, auf dessen Grundlage das gesamte Informationsmodell aufgebaut wird.

Jedes Kernkonzept wird durch ein Kernobjekt repräsentiert. Durch das Hinzufügen von komplexen Eigenschaften sowie internen Komponenten, wird aus einem Kernkonzept ein Kernsubschema. Interne Komponenten werden aufgrund von mehrwertigen oder strukturierten Eigenschaften extrahiert und durch eigene Objekte dargestellt, die über Beziehungen mit dem Kernobjekt verbunden sind.

2. Verbindungsobjekte und daraus resultierendes Verbindungssubschema

Verbindungsobjekte kennzeichnen die Beziehungen zwischen Kernkonzepten im Informationsmodell und drücken damit die gewünschte semantische Verbindung zwischen Kernobjekten aus. Verbindungsobjekte dienen sozusagen der Definition von Links bzw. Listen zur Navigation zwischen sich aufeinander beziehende Objekte. Jede semantische Verbindung zwischen Kernobjekten eines Informationsmodells wird durch eine Beziehung gekennzeichnet.

3. Zugriffsobjekte und daraus resultierende Zugriffssubschemata

Zugriffsobjekte sind sogenannte Hilfsobjekte, um Spezialisierungen oder Klassifizierungen der Kernobjekte vorzunehmen. Sie sind über Beziehungen oder Spezialisierungsverbindungen mit den Kernobjekten verbunden. Im Zugriffssubschema werden klassifizierende Entitäten und spezialisierende Sub-Entitäten unterschieden. Eine klassifizierende Entität ist über eine Beziehung mit dem Kernobjekt verbunden, welches dann die Rolle der kategorisierten Entität spielt. Durch mehrstufige Kategorisierung eines Kernobjektes kann eine Art Hierarchie aufgebaut werden, die den Nutzer zum gewünschten Kernobjekt leitet.

Eine spezialisierende Sub-Entität ist durch eine Generalisierungsbeziehung ("IS A" Beziehung) mit dem Kernobjekt verbunden. Dadurch wird eine spezialisierende Einteilung der Instanzen der Kernentität aufgrund gleicher Eigenschaften vorgenommen. Die Erläuterung der Konzepte des Informationsmodells erfolgt ausführlich in Kapitel 4.2.

4. Personalisierungsobjekte und daraus resultierendes Personalisierungssubschema

Durch Personalisierungsobjekte werden die wichtigsten Eigenschaften der Nutzer oder Nutzergruppen in das Informationsmodell eingebaut, um den Zweck der Personalisierung zu erfüllen. Es werden Entitäten zur Modellierung von Nutzerprofilen oder definierten Nutzergruppen eingefügt, die wiederum über Beziehungen mit Kernobjekten des Informationsmodells verbunden sind, um Objekteigentum, persönliche Vorlieben oder Zugriffsrechte auszudrücken. ([CeriFrat03] S.252-260).

Der Entwurf des Informationsmodells ist ein mehrstufiger Prozess, in dem schrittweise die einzelnen Subschemata aus den definierten Kernobjekten aufgebaut werden. Die hier beschriebene Vorgehensweise zur Entwicklung eines Informationsmodells anhand der 4 verschiedenen Objekttypen und den daraus entstehenden Subschemata ist keine einzuhaltende Vorschrift. Diese Unterscheidung dient vielmehr als Hilftestellung, um ein den Zielen der Anwendung konsistentes Informationsmodell zu entwerfen.

Phase 3 - Hypertextentwurf

In der Phase des Hypertextentwurfs wird auf Grundlage des Informationsmodells und den funktionalen Beschreibungen der eigentliche Hypertext entworfen. Als Hypertext versteht man "eine nicht-lineare Organisation von Objekten, deren netzartige Struktur durch logische Verbindungen (Verweise, Links) zwischen Wissenseinheiten (Knoten, z. B. Texten oder Textteilen) hergestellt wird"([wiki0]).

Die Trennung der Datenmodellierung von der Hypertextmodellierung ermöglicht es, verschiedene Sichten über denselben Daten zu definieren, um komplexe Anforderungen und Bedürfnisse zu erfüllen. So ist es möglich, für verschiedene Nutzergruppen mit unterschiedlichen Bedürfnissen und Zugriffsrechten jeweils eigene Sichten auf den Hypertext zu entwerfen. In der Literatur wird dabei von sogenannten Site Views gesprochen. Da es sich hierbei um verschiedene Sichten auf den gesamten Hypertext handelt, ist der Begriff Hypertext View eindeutiger und wird in den folgenden Ausführungen an Stelle von Site View verwendet.

Ziel des Hypertextentwurfs ist die Ausarbeitung eines konzeptuellen Modells zur Visualisierung der geplanten Topologie und inhaltlichen Struktur der einzelnen Seiten, sowie der Navigationsstruktur der Anwendung, aufgesetzt auf dem zuvor entworfenen Informationsmodell. Die Planung und Umsetzung einer komplexen Webanwendung auf Basis eines visuellen Modells, welches die Funktionen der Anwendung beschreibt, ermöglicht qualitativ hochwertigere und übersichtlichere Planungen und Entwicklungen. Die Hypertextmodellierung ist eine noch sehr junge Disziplin, die den Entwurf von Webanwendungen durch das Hypertextmodell unterstützt. Die Planung und Weiterentwicklung einer komplexen Webanwendung auf Grundlage eines Hypertextmodells ist effektiver, als auf Basis von formalen Beschreibungen oder des reinen Programmcodes.

In der Hypertextmodellierung wird das Informationsmodell zusammen mit den ausgearbeiteten funktionalen Anforderungen, sowie einfachen Sicht-Beschreibungen als Grundlage für den Entwurf des Hypertextmodells verwendet. Das Hypertextmodell spiegelt dann die zu entwickelnde Webanwendung auf einer hohen Abtraktionsebene wider und kann so als Anleitung für die spätere Implementierung verwendet werden.

Die Entwicklung des Hypertextmodells erfolgt in mehreren Verfeinerungsschritten. Der erste Schritt ist eine grobe Gliederung der definierten Hypertext Views in verschiedene Bereiche, sogenannte Areas, um inhaltlich aufeinander bezogene Datenobjekte miteinander zu kombinieren und so die Anwendung inhaltlich sowie physisch zu strukturieren. Eine weitere Verfeinerung erfolgt durch das Hinzufügen von Pages, die als Container für die kleinsten Informationseinheiten, die sogenannten Content Units, dienen. Die Möglichkeiten der Hypertextgliederung werden in Kapitel 4.3 ausführlicher erläutert.

Ein weiterer wichtiger Aspekt beim Entwurf des Hypertextes sind datenmanipulierende Funktionen. Diese können nicht allein durch die Konzepte des Hypertextmodells umgesetzt werden. WebML unterstützt diese Anforderungen durch ein weiteres Modell - das Content Management Modell. Die Konzepte der für den Entwurf einer Webanwendung notwendigen Modelle werden in Kapitel 4 ausführlich erläutert.

Technische Umsetzung

Die technische Umsetzung der Webanwendung erfolgt in den Phasen Architekturentwurf und Implementierung. Der Architekturentwurf befasst sich mit der Auswahl der für die Bedürfnisse der Anwendung notwendigen Hardware, Software und Netzwerkkomponenten. Durch das Hypertextmodell steht dem Entwickler ein konzeptuelles Modell zur Verfügung, das ohne zusätzliche funktionale Beschreibungen die gesamte Funktionalität der Anwendung ausdrückt. In der Implementierungsphase wird die Anwendung auf Grundlage dieses Hypertextmodells in Quellcode umgesetzt.

Die Verwendung des CASE Tools WebRatio bei der Entwicklung einer Webanwendung unterstützt die Phase der Implementierung, indem automatisch Quellcode anhand des Hypertextmodells generiert wird. Dies beschleunigt den Entwicklungsprozess einer datenintensiven Webanwendung, da direkt im Anschluß an die Phase des Hypertextentwurfs eine Grundversion des Programms erzeugt werden kann. Nach Verfeinerungen und Verbesserungen im Hypertextmodell kann dieser Generierungsprozess beliebig oft wiederholt werden.

Schwerpunkt dieser Arbeit ist der Entwurf einer komplexen Webanwendung unter Verwendung der Modelle der WebML. Auf die Phasen Architekturentwurf, Implementierung, Test und Bewertung, sowie Instandhaltung und Entwicklung, wird daher in dieser Abeit nicht näher eingegangen.

Die Modelle der Web Modeling Language

Allgemeines

Die Web Modeling Language stellt Konzepte bereit, um datenintensive Webanwendungen plattformunabhängig zu modellieren. Ziel von WebML ist die Unterstützung von Entwicklern beim Entwurf von komplexen datenintensiven Webanwendungen, das heisst die Erweiterung konventioneller Modellierungsmethoden durch die modelbasierte Beschreibung webanwendungsspezifischer Besonderheiten. WebML ermöglicht es den Entwicklern, die Hauptmerkmale einer Webanwendung ohne detaillierte technische Aspekte darzustellen. Bei der Entwicklung einer datenintensiven Webanwendung werden die verschiedenen Entwurfsphasen durch unterschiedliche Modelle der WebML repräsentiert, denn WebML stellt spezielle grafische Notationen bereit, um die Kompositions- und Navigationsmerkmale von Webanwendungen zu beschreiben. Abbildung 2 stellt die Modelle von WebML und ihre Hierarchie untereinander dar. Das Informationsmodell, Hypertextmodell und Content Management Modell bilden die Grundlage für den Entwurf einer komplexen Webanwendung. Sie sind Schwerpunkt dieses Kapitels und daher in der Grafik gesondert hervorgehoben.

Figure 2. Modelle der Webmodellierungssprache WebML.

Modelle der Webmodellierungssprache WebML.

Die Daten und Informationen, die den Inhalt der Webanwendung beschreiben, werden im sogenannten Informationsmodell dargestellt. Aufbauend auf dem Informationsmodell wird das Hypertextmodell modelliert, welches sich in die zwei Teilmodelle Kompositionsmodell und Navigationsmodell unterteilt. Im Hypertextmodell wird die eigentliche Seiten- und Datenstruktur des Hypertextes festgelegt, sowie deren Navigation untereinander durch die Definition von Links. Es können hier verschiedene Sichten auf den Hypertext hinsichtlich verschiedener Nutzergruppen oder Nutzungsgeräte, wie PDA oder Handy definiert werden.

Das Präsentationsmodell weist dem Hypertext ein allgemeines oder seitenspezifisches Layout zu. Dies erfolgt über ein definiertes XSLT Stylesheet, welches spezielle Layoutvorgaben enthält und damit für den Hypertext oder einzelne Seiten ein bestimmtes Layout definiert.

Das Personalisierungsmodell erlaubt die explizite Modellierung von Nutzern und Nutzergruppen durch Entitäten im Informationsmodell und beschreibt damit die Funktionalität zur Speicherung und Wiederverwendung von nutzer- oder gruppenspezifischen Daten ([WebML] S.3 f.).

Durch das Informationsmodell, das Hypertextmodell und das Präsentationsmodell ist es möglich, nur lesbare Webanwendungen zu entwerfen. Um weitere Anforderungen, wie das Content Management, beim Entwurf einer datenintensiven Anwendung zu berücksichtigen, ist ein weiteres Modell notwendig. Das Content Management Modell definiert Operationen auf Daten bzw. Datenobjekte, wodurch Datenbankinhalte verändert werden können. Dazu gehören Funktionen, wie die Auswertung von Formulareingaben, die Aktualisierung von Daten und das Hinzufügen oder Löschen von Objekten. Diese Operationen können durch zusätzliche grafische Notationselemente erweiternd zum Hypertextmodell hinzugefügt werden ([CeriFrat03] S.137 ff.).

In diesem Kapitel werden die Konzepte der grundlegenden Modelle für den Entwurf von datenintensiven Webanwendungen aufgezeigt. Für die Modelle der Web Modeling Language steht eine grafische und textuelle Notation zur Verfügung, die beide anhand von Beispielen vorgestellt werden.

Informationsmodell

Allgemein

Die Datenmodellierung ist eine aus verschiedenen Bereichen der Informationstechnologie bekannte Disziplin. Das Ziel der allgemeinen Datenmodellierung ist der Entwurf eines konzeptuellen Schemas mit folgenden Eigenschaften:

  • das Schema beinhaltet allgemeingültige Aussagen über den zu modellierenden Realitätsausschnitt des jeweiligen Anwendungsbereiches

  • das Schema ist unabhängig von der späteren technischen Umsetzung und Implementierung der Daten

  • das Schema bildet die Grundlage für die Ableitung der späteren Datenbankstruktur der Anwendung

Bei der Entwicklung einer Webanwendung mit Hilfe des CASE Tools WebRatio, kann anhand des Informationsmodells automatisch eine Datenbankstruktur erzeugt werden.

Das Informationsmodell benutzt die bereits bekannten Konzepte der Datenmodellierung. Es verwendet die Notation des Entity-Relationship Modells oder alternativ von UML-Klassendiagrammen, sowie eine in [WebML] aufgezeigte textuelle Notation in XML-Syntax. Die Grundelemente des Informationsmodells sind Entitäten, Attribute und Beziehungen.

Im Folgenden werden nun die Konzepte des Informationsmodells detaillierter erläutert. Dabei werden anhand von Beispielen aus dem zu modellierenden Projekt „Entwurf eines wissenschaftlichen Online Journals“ die Elemente des Informationsmodells unter Verwendung der UML Notation erklärt.

Entitäten

Eine Entität beschreibt die Eigenschaften einer Menge von gleichartigen Objekten. Entitäten sind “Ausprägungen physikalischer Komponenten oder abstrakter Sachverhalte, die individuell und identifizierbar sind“ ( [Balzert00] S.251) . Eine Menge von gleichartigen Entitäten gehört zu einem Entitätstyp, was einer Klasse in der objektorientierten Modellierung entspricht. Die durch eine Entität beschriebenen Objekte werden auch Instanzen der Entität genannt. Beispiele für Entitäten sind Autor, Beitrag oder Themengebiet. In der grafischen Notation werden Entitäten als Rechtecke dargestellt, mit dem Namen der Entität im oberen Teil des Rechtecks. Abbildung 3 zeigt die grafische Notation von 3 Entitäten: Author, Contribution und Topic.

Figure 3. Grafische Notation der Entitäten: Author, Contribution, Topic.

Grafische Notation der Entitäten: Author, Contribution, Topic.

Entitäten werden durch das Element ENTITY gekennzeichnet und besitzen einen eindeutigen Namen, benannt durch das Elementattribut id.

Die in Abbildung 3 dargestellten Entitäten werden in textueller Notation wie folgt beschrieben:

<ENTITY id = “Author“></ENTITY>
<ENTITY id = “Contribution“> </ENTITY>
<ENTITY id = “Topic“> </ENTITY>

Attribute

Alle Instanzen einer Entität werden durch die gleichen Eigenschaften beschrieben. Diese Eigenschaften werden in Form von Attributen der zugehörigen Entität dargestellt. Attribute werden durch ihren Namen und ihren Typ definiert, wobei der Attributname innerhalb der zugehörigen Entität eindeutig sein muss. Beispiele für Attribute sind Name, Titel oder Datum.

Attribute können sogenannte Null-Werte besitzen, das heisst nicht jedes vorhandene Attribut muss einen Wert zugewiesen bekommen. Es gibt zwei Möglichkeiten, diese Information zu deuten:

  • die Instanz besitzt keinen Wert für dieses spezielle Attribut

  • der Wert des Attributes ist nicht bekannt

Jede Instanz einer Entität muss einmalig sein, das heisst unterscheidbar von den anderen Instanzen dieser Entität. Die Instanzen einer Entität besitzen also die gleichen Attribute, jedoch individuelle Attributwerte. Attribute, die eindeutig eine Instanz identifizieren, werden Schlüsselattribute genannt. Genau eine Instanz muss also durch ihre Schlüsselattribute eindeutig bestimmbar sein. Man unterscheidet beschreibende Attribute, die zur Beschreibung der für die Anwendung wesentlichen Eigenschaften von Entitäten dienen, und identifizierende Attribute, zur eindeutigen Bestimmung einer Instanz ([Balzert00] S228 f.). Besitzt eine Entität mehrere identifizierende Attribute, wird ein so genannter Primärschlüssel bestimmt. Schlüssel müssen außerdem besondere Einschränkungen erfüllen:

Minimalität

Der definierte Primärschlüssel sollte eine minimale Anzahl an Attributen beinhalten, das heisst wird ein Attribut aus der Schlüsselmenge entfernt geht die eindeutige Identifizierbarkeit verloren.

Eindeutigkeit

Der Attributwert des Schlüssels darf für zwei Instanzen nicht den gleichen Wert besitzen, da sonst ebenfalls die Eindeutigkeit verloren geht.

Definitionseinhaltung

Schlüsselattribute dürfen keine Null-Werte besitzen, das heisst es müssen für jede Instanz der Entität Attributwerte vorhanden sein.

Schlüsselattribute werden in der UML-Notation durch das Hinzufügen des Wortes {unique} hinter das jeweilige Attribut gekennzeichnet. Um eine absolute Eindeutigkeit eines Schlüsselattributs zwischen Instanzen einer Entität zu garantieren, kann ein „künstlicher“ Schlüssel verwendet werden. Dabei handelt es sich um ein frei eingefügtes Attribut id (Objektidentifikation), welches in jedem Fall eindeutig ist. ([CeriFrat03] S.63 f.)

Die Abbildung 4 zeigt die grafische Notation der Entitäten Author, Contribution und Topic mit ihren Attributen und Schlüsselattributen.

Figure 4. Grafische Notation der Entitäten mit Attributen und Schlüsselattributen.

Grafische Notation der Entitäten mit Attributen und Schlüsselattributen.

Attribute einer Entität werden durch das Element ATTRIBUTE innerhalb der entsprechenden Entität, das heisst im einschließenden ENTITY-Tag, notiert. Attribute haben ebenfalls einen eindeutigen Namen, gekennzeichnet durch das Elementattribut id .

Die grafische Notation aus Abbildung 4 wird in textueller Notation wie folgt dargestellt:

<ENTITY id = “Author“> 
 <ATTRIBUTE id ="id"/> 
 <ATTRIBUTE id ="username"/>
 <ATTRIBUTE id ="password"/> 
 <ATTRIBUTE id ="lastname"/> 
 <ATTRIBUTE id ="firstname"/> 
 <ATTRIBUTE id ="email"/> 
 <ATTRIBUTE id ="photo"/> 
 <ATTRIBUTE id ="biography"/> 
</ENTITY>

<ENTITY id = “Contribution“> 
 <ATTRIBUTE id ="id"/> 
 <ATTRIBUTE id ="title"/> 
 <ATTRIBUTE id ="date"/> 
</ENTITY>

<ENTITY id = “Topic“>
 <ATTRIBUTE id ="id"/> 
 <ATTRIBUTE id ="topicName"/> 
 <ATTRIBUTE id ="description"/> 
</ENTITY> 

Attributtypen

Attribute beschreiben die Daten, die von den Instanzen einer Entität angenommen werden können. Diese Attribute können verschiedenen Typen zugeordnet sein. Sie können demnach Werte aus bestimmten Wertebereichen annehmen. Die Definition von Attributtypen dient im Informationsmodell dazu, das Attribut aus anwendungsorientierter Sicht möglichst präzise zu beschreiben. Auch wird dadurch die Implementierung der Daten der Anwendung bestimmt.

Attributtypen werden im Datenmodell rechts neben dem zugehörigen Attributnamen getrennt durch einen Doppelpunkt notiert, in der Form:

attributName: attributType

In folgender Tabelle sind die wichtigsten Attributtypen aufgelistet.

DatentypBeschreibung
ZEICHENKETTEN 
Stringkurze Folge von Zeichen
Textlange Folge von Zeichen, Angabe des MIME Typs zur Verfeinerung, z.B.: text/html
NUMERISCHE DATENTYPEN 
IntegerGanze Zahl
FloatGleitkommazahl
BooleanWahrheitswert
BUSINESSKOMPONENTEN 
DateDatum
TimeZeit
URLUniform Resource Locator einer Webseite
BLOBBinary Large OBject, Daten die aufgrund der Größe speziell behandelt werden müssen (Bild, Video)
SONSTIGE 
EnumerationAufzählung, benutzerdefinierte Werte z.B.: Wochentage mit Werten von Montag bis Freitag

Beziehungen

Beziehungen beschreiben die Verbindung zwischen Entitäten, genauer gesagt zwischen den Instanzen von Entitäten. In der Datenmodellierung werden binäre und n-äre Beziehungen unterschieden. Die binäre Beziehung verbindet Objekte von zwei Entitäten miteinander und stellt damit die einfachste Form einer Beziehung dar. Binäre Beziehungen werden grafisch durch eine einfache Linie zwischen den zwei beteiligten Entitäten dargestellt. Beziehungen zwischen Entitäten können mit Beziehungsnamen gekennzeichnet werden, um die Bedeutung dieser Beziehung zu beschreiben. Der Beziehungsname stellt dabei im Allgemeinen nur eine Richtung der Beziehung dar, kann aber für beide Leserichtungen angegeben werden. Binäre Beziehungen können zusätzlich durch maximal zwei Rollennamen beschrieben werden. Jeder Rollenname drückt dabei die Funktion der an der Beziehung beteiligten Entität aus und wird an das jeweilige Ende einer Beziehung notiert. Ebenfalls an das Ende einer Beziehung kann die zu einer Entität gehörende Wertigkeit bzw. Kardinalität angegeben werden. Kardinalitäten spezifizieren wieviele Instanzen der Quell-Entität mit den Instanzen der Ziel-Entität in Beziehung stehen können oder müssen.

Basierend auf den Kardinalitätsangaben wird zwischen Kann-Beziehungen und Muss-Beziehungen unterschieden. Eine Beziehung ist für die Quell-Entität optional, wenn die minimale Kardinalität 0 ist, das bedeutet keine Instanz dieser Entität muss an der Beziehung beteiligt sein. Ist die minimale Kardinalität der Quell-Entität 1, so muss dagegen mindestens eine Instanz der Quell-Entität mit einer Instanz der Ziel-Entität in Beziehung stehen. Es handelt sich dann um eine Muss-Beziehung und bedeutet, dass eine Instanz der Quell-Entität nur in Verbindung mit einer oder mehreren Instanzen der beteiligten Ziel-Entität existieren kann. In Abhängigkeit von den maximalen Kardinalitätsangaben einer Beziehung ergeben sich folgende Bezeichnungen für Beziehungen.

one-to-one: Beide Beziehungsrollen haben als maximale Kardinalität den Wert 1.

one-to-many / many-to-one: Eine Beziehungsrolle besitzt als maximale Kardinalität den Wert 1, die andere Beziehungsrolle den Maximalwert *, das bedeutet beliebig viele Instanzen der Entität können an der Beziehung beteiligt sein.

many-to-many: Beide Beziehungsrollen besitzen als maximale Kardinalität den Wert *.

Eine Beziehung, an der mehr als zwei Entitäten beteiligt sind, nennt man n-äre Beziehung. N-äre Beziehungen lassen sich jedoch gleichermassen durch eine Kombination aus Entitäten und mehreren binären Beziehungen ausdrücken. Aus diesem Grund sollten sie, wenn möglich, zur Vereinfachung des Informationsmodells vermieden werden. ([CeriFrat03] S.67-70, [Balzert00] S.187 ff.)

Abbildung 5 zeigt die grafische Notation von drei Entitäten mit ihren Attributen und zugehörigen Atrtributtypen. Die Entitäten sind durch binäre Beziehungen mit definierten Beziehunsnamen und Kardinalitätsangaben verbunden. Die Angabe der Kardinalitäten erfolgt in Partizipationssemantik. Die Entität Author ist über die Beziehung AuthorToContr mit der Entität Contribution verbunden. Zu einem Autor gehören keine oder mehrere veröffentlichte Beiträge und zu einem Beitrag mindenstens ein oder mehrere Autoren. Die Beziehung ContToTopic zwischen den Entitäten Contribution und Topic legt fest, dass ein Beitrag genau zu einem Thema gehört und einem Thema kein oder mehrere Beiträge zugeordnet werden können.

Figure 5. Grafische Notation der Entitäten Author, Contribution und Topic mit Atrtributen, Attributtypen und Beziehungen.

Grafische Notation der Entitäten Author, Contribution und Topic mit Atrtributen, Attributtypen und Beziehungen.

Grafische Notation aus Abbildung 5 in textueller Darstellung:

<ENTITY id = “Author“>
 <ATTRIBUTE id ="id" type = ”Integer”/> 
 <ATTRIBUTE id ="username" type = ”String”/> 
 <ATTRIBUTE id ="password" type = ”Passowrd”/> 
 <ATTRIBUTE id ="lastname" type = ”String”/>
 <ATTRIBUTE id ="firstname" type = ”String”/> 
 <ATTRIBUTE id ="email" type = ”String”/> 
 <ATTRIBUTE id ="photo" type = ”BLOB”/> 
 <ATTRIBUTE id ="biography" type = ”Text”/> 
 <ATTRIBUTE id = “NrOfContr“ type = ”Number” 
  value=”Count (Author.AuthorToContr) ”/> //abgeleitetes Attribut
 <RELATIONSHIP id=" AuthorToContr" to="Author" inverse="ContrToAuthor" 
  minCard="0" maxCard="*"/>
</ENTITY> 

<ENTITY id = “Contribution“> 
 <ATTRIBUTE id ="id" type = ”Integer”/> 
 <ATTRIBUTE id ="title" type = ”String”/> 
 <ATTRIBUTE id ="date" type = ”Date”/> 
 <RELATIONSHIP id=" ContrToAuthor" to="Contribution" inverse="AuthorToContr" 
  minCard="1" maxCard="*"/>
 <RELATIONSHIP id=" ContrToTopic" to="Topic" inverse="TopicToContr" 
  minCard="1" maxCard="1"/>
</ENTITY> 

<ENTITY id = “Topic“> 
 <ATTRIBUTE id ="id" type = ”Integer”/> 
 <ATTRIBUTE id ="topicName" type = ”String”/> 
 <ATTRIBUTE id ="description" type = ”Text”/> 
 <RELATIONSHIP id=" TopicToContr" to="Contribution" inverse="ContrToTopic" 
  minCard="0" maxCard="*"/>
</ENTITY> 

Zwischen dem Start-Tag und End-Tag des Entitätelementes ENTITY werden die Attribute und Beziehungen der Entität durch die Elemente ATTRIBUTE und RELATIONSHIP dargestellt. Durch das Elementattribut type wird der Typ eines Attributs beschrieben. Value definiert die Berechnungsvorschrift eines abgeleiteten Attributs oder einer abgeleiteten Beziehung.

Werte von sogenannten abgeleiteten Attributen oder abgeleiteten Beziehungen können jederzeit aus anderen Attributwerten oder Beziehungen zwischen Entitäten ermittelt werden. Abgeleitete Attribute und Beziehungen werden durch ein vorangestelltes „/“ mit dazugehörender Berechnungsvorschrift im Informationsmodell gekennzeichnet, in der Form:

/ Attributname { Berechnungsvorschrift }

Zum Beispiel kann die Anzahl der Beiträge (NrOfContr) der Entität Author über die Beziehung AuthorToContr berechnet werden:

/ NrOfConr { Count (Author.AuthorToContr) }

Abgeleitete Attribute dürfen durch die Anwendung selbst nicht verändert werden. Als Standard zur Beschreibung von Ableitungsregeln oder Restriktionen wird die in UML definierte Object Constraint Language (OCL) verwendet. ([CeriFrat03] S.72)

Generalisierungshierarchie („IS-A“ Hierarchie)

Entitäten können im Informationsmodell hierarchisch organisiert werden. Es gibt eine Super-Entität und eine oder mehrere Sub-Entitäten. Generalisierung bzw. Vererbung bedeutet, dass eine oder mehrere Sub-Entitäten über die Eigenschaften und Beziehungen der Super-Entität verfügen. Die Sub-Entitäten erben somit alle Attribute und Beziehungen der übergeordneten Entität und besitzen in der Regel weitere zusätzliche Attribute und Beziehungen. Solch eine Vererbungshierarchie beschreibt nicht nur die Vererbung von Attributen und Beziehungen, sondern muss immer eine Spezialisierung darstellen. Das heisst, zwischen einer Sub-Entität und einer Super-Entität muss eine „ist ein“ Beziehung bestehen. Es liegt dann eine Generalisierungshierarchie bzw. „IS-A“ Hierarchie vor. Vererbung wird nicht nur in der Datenmodellierung angewendet, sondern ist ebenso aus dem Bereich des objektorientierten Entwurfs bekannt. Im Bereich der Datenmodellierung ist es üblich eine eher vereinfachte Form der Generalisierungshierarchie mit einigen Einschränkungen anzuwenden. Folgende Regeln werden dabei genannt:

1. Jede Entität ist Sub-Entität höchstens einer Super-Entität.

2. Jede Instanz einer Super-Entität ist spezialisiert in ausschließlich eine Sub-Entität.

3. Jede Entität gehört zu höchstens einer Generalisierungshierarchie.

Die genannten Beschränkungen vermindern zwar die Ausdrucksmöglichkeiten im Informationsmodell, vereinfachen aber wiederum die Implementierung der Anwendung bei der Nutzung herkömmlicher Datenbanktechnologien aufgrund der Vermeidung zu vieler Hierarchieebenen. ([CeriFrat03] S. 66 f.)

Die Generalisierungsbeziehungen zwischen Entitäten werden grafisch durch Pfeile gekennzeichnet, deren Pfeilspitze zur jeweiligen Super-Entität zeigt.

Abbildung 6 zeigt die Generalisierungsbeziehungen zwischen der Super-Entität User und den Sub-Entitäten Author, Editor, Reviewer und Administrator. Die Sub-Entitäten erben die Attribute von User. Sub-Entität Author enthält zusätzlich weitere beschreibende Attribute. Das bedeutet Author, Editor, Reviewer und Administrator sind User mit möglichen zusätzlichen Attributen.

Figure 6. Generalisierungshierarchie / Spezialisierung.

Generalisierungshierarchie / Spezialisierung.

Hypertextmodell

Allgemein

Das Hypertextmodell beschreibt die Topologie der einzelnen Webseiten und deren Informationseinheiten, sowie die Navigation zwischen ihnen mit Hilfe von Links. Der Entwurf des Hypertextmodells teilt sich damit in die Teilmodelle Kompositionsmodell und Navigationsmodell.

Für jede definierte Hypertext View wird ein eigenes Hypertextmodell entworfen. Die Hauptelemente des Hypertextmodells sind Areas, Pages, Content Units und Links. Ziel dieses Kapitels ist die Erläuterung der wichtigsten Konzepte des Hypertextmodells anhand von Beispielen aus den Hypertextmodellen des Beispielprojektes.

Für das Hypertextmodell sind zwei alternative grafische Notationen vorhanden. Die WebML-Syntax in Form einer neu entworfenen grafischen Notation und die Darstellung in alternativer UML-Syntax. Bei der Erläuterung der wichtigsten Content Units werden einführend beide Notationsmöglichkeiten dargestellt.

Kompositionsmodell

Das Kompositionsmodell befasst sich mit dem Aufbau des Hypertextes aus Areas und Pages. Es werden hier die verschiedenen Typen von Content Units in einzelnen Pages zusammengefasst, um dann in Kombination dem Nutzer als Inhalt präsentiert zu werden. Es werden dabei folgende Content Units unterschieden:

  • Data Units

  • Multidata Units

  • Index Units

  • Hierarchical Index Units

  • Entry Units

  • Scroller Units

In den folgenden Unterkapiteln werden die einzelnen Content Units anhand von Beispielen erläutert. Zuvor werden die Möglichkeiten zur Strukturierung eines Hypertextes aufgezeigt.

Hypertext Gliederung

Um große und komplexe Webanwendungen hierarchisch zu gliedern, wird der Hypertext in Hypertext Views, Areas und Pages strukturiert. Hypertext Views werden durch einen nutzerdefinierten Namen gekennzeichnet und sind die größten Informationseinheiten, um den Hypertext entsprechend der Funktionen und Zugriffsrechte verschiedener Nutzergruppen zu gliedern. Hypertext Views können öffentlich (public) und privat (protected), das heisst nur über Authentifizierung zugänglich, sein. Areas sind Gruppierungen von Pages zur Trennung thematisch aufeinander bezogener Pages von anderen Areas und Pages. Zur weiteren hierarchischen Gliederung können sie zusätzlich weitere sub-areas enthalten. Pages sind die Informationseinheiten, die dem Nutzer als Ganzes angezeigt werden und dienen als Container für die kleinsten Informationseinheiten eines Hypertextes, die sogenannten Content Units. Eine Page enthält somit eine Menge verschiedener Typen von Content Units, die in Kombination den eigentlichen Inhalt einer Webseite bestimmen.

Abbildung 7 zeigt die hier beschriebenen Gliederungsmöglichkeiten eines Hypertextes nochmals in grafischer Form. Ein Hypertext kann in mehrere Hypertext Views unterteilt werden. Für jede Hypertext View wird ein Hypertextmodell entworfen aus Elementen wie Areas, Pages und Content Units. Areas und Pages können weitere sub-areas bzw sub-pages enthalten.

Figure 7. Hauptelemente des Hypertextmodells.

Hauptelemente des Hypertextmodells.

Home Page, Default Page, Landmark Page

Areas und Pages haben einige wichtige Eigenschaften die im folgenden Abschnitt kurz erläutert werden.

Die Home Page ist die Seite, die dem Nutzer nach Aufruf der Anwendung oder nach dem Einloggen angezeigt wird. Sie muss innerhalb einer Hypertext View einmalig sein. In der grafischen Notation wird die Home Page durch ein "H" innerhalb der Page gekennzeichnet. In der textuellen Notaton wird der Page-Definition das Wort home hinzugefügt.

Die Default Page ist die Seite, die als erstes dem Nutzer angezeigt wird, wenn auf deren einschließende Area zugegriffen wird. Auch die Default Page muss innerhalb einer Area einmalig sein. Sie wird durch ein "D" innerhalb der Page gekennzeichnet. In der textuellen Notation wird der Page-Definition das Schlüsselwort default hinzugefügt.

Eine Page, die durch ein "L" als landmark gekennzeichnet ist, kann von allen anderen Pages und Areas innerhalb der umgebenden Area oder Hypertext View erreicht werden. Als landmark gekennzeichnete Pages und Areas sind für den Nutzer als Links sichtbar, und bilden die Menüstruktur der Webanwendung. In der textuellen Notation wird dieser Page das Wort landmark angefügt. Areas können genauso wie Pages mit den Eigenschaften landmark und default verbunden werden.([CeriFrat03] S.112ff. )

Die grafische Notation einer typischen Hypertexthierarchie wird in Abbildung 8 dargestellt. Die Hypertext View enthält mehrere Areas mit wiederum mehreren Pages, die sich thematisch aufeinander beziehen. Die Contribution Area enthält die Page Contribution zur Auflistung aller Beiträge, sowie eine Page Search zur entsprechenden Suche nach Beiträgen. Die Author Area befasst sich mit den Autoren der Beiträge und enthält eine Page All Authors zur Auflistung aller Autoren, sowie eine Page Search zur Suche nach bestimmten Autoren. Ausserdem enthält die Hypertext View eine Home Page ohne Zuordnung zu einer bestimmten Area. Die Home Page ist zusätzlich als landmark gekennzeichnet und somit von allen anderen Areas oder Pages aus erreichbar. Contribution Area und Author Area sind ebenfalls landmark und damit von allen anderen Pages oder weiteren Areas innerhalb der Hypertext View zugänglich. Die Pages Contributions und All Authors werden als erstes bei Zugriff auf deren umgebenden Area angezeigt, da sie als Default Pages gekennzeichnet wurden.

In der textuellen Notation werden als erstes die Elemente aufgelistet, die direkt von der Hypertext View eingeschlossen sind. Anschließend folgt die separate Definition der einzelnen Areas und deren enthaltende Pages. Der eingeführte Begriff Hypertext View anstelle von Site View wird nur bei Beschreibungen vorgenommen und nicht in der textuellen Notation weiter verwendet.

Figure 8. Grafische Notation (in WebML-Syntax) einer Hypertext View mit 2 Areas und 5 Pages.

Grafische Notation (in WebML-Syntax) einer Hypertext View mit 2 Areas und 5 Pages.

Textuelle Notation der Hypertext View aus Abbildung 8:

siteview Default
(areas Contribution Area landmark, Author Area landmark;
 pages Home home landmark)

area Contribution Area
(pages Search, Contributions default)

area Author Area
(pages AllAuthors default, Search)

AND sub-pages, OR sub-pages

WebML ermöglicht ausserdem die Verschachtelung von Pages in sub-pages, um auch die physische Unterteilung von Pages komplexer Webanwendungen zu modellieren. Es wird zwischen konjunktiv verschachtelten Pages, so genannten AND sub-pages, sowie disjunktiv verschachtelten Pages, den so genannten OR sub-pages, unterschieden. AND sub-pages dienen der Einteilung einer Page in mehrere Bereiche, um parallel verschiedene Inhalte auf einer Page darzustellen und sind somit vergleichbar mit Frames in HTML. ([CeriFrat]S.114 ff.) Die Page Contributions in Abbildung 9 enthält zwei AND sub-pages: Listing und Selected. Listing enthält zwei Index Units Actual und Past zur Auflistung aktueller und älterer Beiträge. Selected enthält eine Data Unit Contribution zur Anzeige der Informationen zu einem ausgewählten Beitrag. AND sub-pages werden benutzt, um einen Bereich einer Page zu fixieren, während der andere Bereich wechselnde Informationen entsprechend einer Nutzeraktion anzeigt. In diesem Beispiel ändert sich nach Auswahl eines Beitrags aus Actual oder Past nur der Inhalt der Page Selected, Listing bleibt dabei unverändert. Die textuelle Notation der Page Contributions enthält als erstes die Liste der enthaltenden and-pages. Diese werden anschließend nochmal einzeln einschließlich der enthaltenen Content Units definiert.

Figure 9. Grafische Notation: verschachtelte AND sub-pages.

Grafische Notation: verschachtelte AND sub-pages.

Textuelle Notation der AND sub-pages aus Abbildung 9:

page Contributions
(and-pages Listing, Selected)

page Listing
(units Actual, Past)

page Selected
(units Contribution)

OR sub-pages werden verwendet, um alternative Inhalte in einem bestimmten Bereich einer Page anzuzeigen, das heisst die Anzeige der einen sub-page wird durch die Anzeige der anderen sub-page ersetzt.

Abbildung 10 zeigt die AND sub-pages Listing und Information und die OR sub-pages Author und Contribution innerhalb der Page Information. Die Page InfoPage zeigt die Auflistung von Autoren und Beiträgen (Listing), sowie die Detailinformationen entweder eines ausgewählten Autors oder eines Beitrags. Die Wahl der Anzeige von Autoreninformation oder Beitragsinformation erfordert die Nutzung von OR sub-pages. Nach Auswahl eines Autors oder Beitrags ändert sich nicht nur das Objekt, welches angezeigt werden soll, sondern der gesamte Aufbau der Page Information. Es erfolgt also je nach Nutzeraktion entweder die Anzeige der Page Author oder der Page Contribution. ([CeriFrat]S.116 f.) Pages die OR sub-pages enthalten, haben in der grafischen Notation eine andere Füllfarbe.

Figure 10. Grafische Notation: AND sub-pages und OR sub-pages

Grafische Notation: AND sub-pages und OR sub-pages

Textuelle Notation der OR sub-pages aus Abbildung 10:

page Information
(or-pages Author, Contribution)

page Author
(units AuthorInfo)

page Contribution
(units Contribution)

Content Units

Content Units stellen die kleinsten Einheiten zur Beschreibung des Inhalts einer Webanwendung dar. Sie sind die Bausteine von Pages, die dem Nutzer als Einheit präsentiert werden. Pages und Content Units werden dabei so miteinander verknüpft, dass eine Hypertextstruktur entsteht. Die Content Units Data Unit, Multidata Unit, Index Unit, Hierarchical Index Unit und Scroller Unit dienen der Veröffentlichung bzw. Darstellung von Informationen. Jede informationsdarstellende Content Unit ist mit einer Entität des unterliegenden Datenschemas verknüpft. Data Units und Multidata Units beziehen sich dabei auf aktuelle Daten ihnen zugeordneter Instanzen einer Entität. Index Units, Hierarchical Index Units und Scroller Units beziehen sich auf eine Menge von Instanzen. Entry Units dienen hingegen der Aufnahme von Informationen durch Nutzereingaben durch entsprechende Eingabefelder. Die Content Units zur Darstellung von Informationen repräsentieren den Inhalt des zu Grunde liegenden Datenschemas, also dem in der Phase des Datenentwurfs definierten Informationsmodells. Im Hypertextmodell ist es daher erforderlich zu spezifizieren, welche Content Unit mit welcher Entität aus dem Informationsmodell in Beziehung steht. Dazu werden folgende zwei Konzepte von WebML benutzt:

  • Quell-Entität

    Die Quellentität Source, ist der Name der Entität aus dem Informationsmodell, von der die entsprechende Content Unit ihren Inhalt erhält. Diese Quell-Entität bestimmt damit den Typ der Instanzen, deren Daten bzw. Attribute den Inhalt der Content Unit darstellen.

  • Selektor

    Der Selektor ist eine Art Berechnungsvorschrift, um eine gewünschte Instanz oder eine Instanzmenge einer Entität zu bestimmen. Dabei handelt es sich um Verknüpfungen elementarer Bedingungen, Konstanten oder Ausdrücke bezüglich Attributen oder Beziehungen, die der entsprechenden Entität zugeordnet sind. Ein Selektor nutzt bei der Berechnung Parameter, sofern diese über eingehende Links einer Unit transportiert werden. Man nennt sie dann parametrische Selektoren. Neben der Konjunktion von vergleichenden Ausdrücken auf Attribute, wie [attribute1=value1], [attribute2<value2], werden zwei Formen der Disjunktion unterschieden:

    Werte-Disjunktion: 
    Ein einzelner Attributwert wird mit einer Menge von Werten verglichen in der Form :
    [attribute operator value 1| value 2 |  ...  | value n]

    Attribut-Disjunktion: 
    Eine Menge von Attributen wird mit einem einzelnen Wert verglichen in der Form:
    [attribute 1 | attribute 2 |  ...  | attribute n operator value].
    ([CeriFrat03] S.79 ff.) 

Content Units besitzen eine grafische Notation zur Darstellung der wichtigsten Eigenschaften und eine textuelle Notation zur Beschreibung von Informationen, die nicht aus der grafischen Notation ersichtlich sind. Content Units werden durch ein Rechteck dargestellt, innerhalb dessen sich ein nutzerdefinierter Name, sowie ein den Content Unit Typ identifizierendes Symbol befindet. Quelle und Selektor werden unterhalb des Rechtecks notiert.

Data Unit

Eine Data Unit stellt die Daten einer einzelnen Instanz der zugeordneten Entität dar. Sie wird beschrieben durch einen nutzerdefinierten Namen, die Angabe der Quell-Entität, einen optionalen Selektor und entsprechend zugeordneten Attributen der Quell-Entität. Abbildung 11 zeigt ein Beispiel einer Data Unit in WebML-Notation und der ihr zugeordneten Entität Author mit folgenden Eigenschaften:

Nutzerdefinierter Name: AuthorInfo
Quell-Entität: Author
Selektor: [lastname="Ceri"] [firstname="Stefano"]

Zugeordnete Attribute: firstname, lastname, email, photo
Die Attribute die bei der späteren Darstellung sichtbar sein sollen .

Figure 11. Grafische Notation der Data Unit AuthorInfo mit zugehöriger Entität.

Grafische Notation der Data Unit AuthorInfo mit zugehöriger Entität.

Die Data Unit AuthorInfo bezieht sich auf die Entität Author des Informationsmodells. Author erhält zusätzlich die Attribute der Entität User aufgrund der Generalisierungsbeziehung zwischen User und Author. Unter der Annahme, dass nicht nur id Schlüsselattribut ist, sondern auch die Kombination der Attribute lastname und firstname, bestimmen somit die Selektoren [lastname="Ceri"], [firstname="Stefano"] eine eindeutige Instanz. In der grafischen Notation von AuthorInfo sind die zugeordneten Attribute nicht ersichtlich. Diese zusätzlichen Informationen werden durch die textuelle Notation hinzugefügt.

Die Definition einer Data Unit wird durch das Element DataUnit beschrieben, innerhalb dem dann die Quell-Entität (source), der Selektor (selector) und die zugeordneten Attribute (attributes) definiert werden. ([CeriFrat03] S.80f, [WebML] S. 7 f.)

Es können auch mehrere Data Units über der selben Instanz einer Entität definiert werden, indem eine unterschiedliche Anzahl von Attributen den Data Units zugeordnet wird, um Kurzinformationen und Detailinformationen eines Autors anzuzeigen.

Textuelle Notation der Data Unit AuthorInfo aus Abbildung 11:

DataUnit AuthorInfo
(source Author;
 selector lastname="Ceri", firstname="Stefano";
 attributes firstname, lastname, email, photo)


Abbildung 12 zeigt die alternative UML-Syntax der grafischen Notation der Data Unit AuthorInfo, sowie die allgemeine UML-Syntax einer Data Unit (farbig hinterlegt). In der UML-Syntax ist eine Data Unit immer mit der zugehörigen Entität des Informationsmodells verbunden, wodurch diese Notation im Vergleich zur WebML-Syntax wesentlich komplexer ist. Andererseits sind bei dieser Notation die der Data Unit zugewiesenen Attribute der unterliegenden Entität sichtbar. Die Selektorbedingung wird hier an der Verbindungslinie zwischen Data Unit AuthorInfo und der Entität Author notiert.

Figure 12. Alternative UML-Syntax einer Data Unit allgemein und speziell für Data Unit AuthorInfo.

Alternative UML-Syntax einer Data Unit allgemein und speziell für Data Unit AuthorInfo.

Multidata Unit

Eine Multidata Unit bezieht sich auf eine Menge von Instanzen der gleichen Entität und stellt diese als Zusammenfassung verschiedener Data Units dar. Eine Multidata Unit wird durch einen nutzerdefinierten Namen, die Zuordnung einer Quell-Entität, die Definition eines optionalen Selektors, die zugeordneten Attribute und eine optionale Sortierbedingung (Order Clause) beschrieben. Abbildung 13 zeigt ein Beispiel einer Multidata Unit in WebML-Notation und die ihr zugeordnete Entität Contribution mit folgenden Eigenschaften:

Nutzerdefinierter Name: Contributions
Quell-Entität: Contribution
Selektor: [title contains "WebML"]

Zugeordnete Attribute: (title, date)
Die Attribute, die bei der späteren Darstellung für jede Instanz der Multidata Unit sichtbar sein 
sollen. 

Sortierbedingung: date descending
Attribute, die zur Sortierung der Instanzen der Multidata Unit genutzt werden.
Mögliche Sortierkriterien sind ascending(aufsteigend) und descending(absteigend), 
wobei ascending als Defaultwert festgelegt ist. 

Wird kein Selektor definiert, werden alle vorhandenen Instanzen der zugeordneten Entität dargestellt.

Figure 13. Grafische Notation der Multidata Unit Contributions mit zugehöriger Entität.

Grafische Notation der Multidata Unit Contributions mit zugehöriger Entität.

Die Multidata Unit Contributions bezieht sich auf die Entität Contribution des Informationsmodells. Der Selektor [title contains "WebML"] bestimmt mehrere Instanzen der Entität, deren Titel das Wort "WebML" enthält, die dann mit den entsprechenden Attributen angezeigt werden. Die Attribute, sowie die Sortierbedingung sind als zusätzliche Informationen in der textellen Notation vorhanden. Die Definition einer Multidata Unit wird durch das Element MultidataUnit beschrieben, in dem die Quell-Entität (source), der Selektor (selector), die zugeordneten Attribute (attributes) und die Sortierbedingung (orderby) definiert werden. ([CeriFrat03] S.82f., [WebML] S. 8)

Textuelle Notation der Multidata Unit aus Abbildung 13:

MultidataUnit Contributions
(source Contribution;
 selector title contains "WebML";
 attributes date, title;
 orderby date descending)

Abbildung 14 stellt die alternative UML-Syntax der Multidata Unit Contributions, gemeinsam mit der allgemeinen Syntax für Multidata Units dar. Die Multidata Unit Contributions ist mit der ihr zugeordneten Entität Contribution verbunden. Die zusätzlich in der textuellen Notation vorhandenen Informationen, wie die zugewiesenen Attribute und die Sortierbedingung, sind in der UML-Syntax sichtbar.

Figure 14. Alternative UML-Syntax einer Multidata Unit allgemein und speziell für Multidata Unit Contributions.

Alternative UML-Syntax einer Multidata Unit allgemein und speziell für Multidata Unit Contributions.

Index Unit

Eine Index Unit stellt eine Menge von Instanzen der selben Entität als Liste dar, wobei jede Instanz als ein Eintrag der Liste aufzufassen ist. Index Units werden benutzt, um einen einzelnen Eintrag der Liste auszuwählen. Anschließend können z.B.: detailliertere Informationen der ausgewählten Instanz, durch eine mit der Index Unit verbundene Data Unit, angezeigt werden. Dies stellt auch den Unterschied zur Multidata Unit dar. Eine Index Unit wird durch einen nutzerdefinierten Namen, eine Quell-Entität, einen optionalen Selektor, die zugeordneten Attribute und eine optionale Sortierbedingung beschrieben. Eine Variante zur Auswahl mehrerer Instanzen aus einer Liste ist die Multichoice Index Unit. Verschiedene Einträge können über entsprechende Checkboxen ausgewählt werden. In Abbildung 15 wird die grafische Notation in WebML-Syntax einer einfachen Index Unit (a) und einer Multichoice Index Unit (b) RubricList mit folgenen Eigenschaften dargestellt:

Nutzerdefinierter Name: RubricList
Quell-Entität: Rubric
Selektor: ohne Selektor 
Zugeordnete Attribute: rubricName
Sortierbedingung: rubricName (ascending als Default)

Figure 15. Grafische Notation der Index Unit a) und Multichoice Index Unit b) RubricList mit zugehöriger Entität.

Grafische Notation der Index Unit a) und Multichoice Index Unit b) RubricList mit zugehöriger Entität.

Die Index Unit RubricList ist der Entität Rubric zugeordnet. Da kein Selektor definiert wurde, werden alle Instanzen von Rubric mit ihrem Attribut rubricName aufgelistet. Die nicht aus der grafischen Darstellung ersichtlichen zusätzlichen Informationen, wie Attribute und Sortierbedingung, sind wieder in der textuellen Notation vorhanden. Die textuelle Notation einer Index Unit und einer Multichoice Index Unit unterscheidet sich nur durch das Schlüsselwort multi-choice, welches der Deklaration der Multichoice Index Unit hinzugefügt wird. ( [CeriFrat03] S.83 ff., [WebML] S. 9 f.)

Textuelle Notation der Index Unit aus Abbildung 15:

IndexUnit RubricList
(source Rubric;
 attributes rubricName;
 orderby rubricName)


Textuelle Notation der Multichoice Index Unit aus Abbildung 15:

IndexUnit RubricList multi-choice
(source Rubric;
 attributes rubricName;
 orderby rubricName)


Abbildung 16 zeigt die alternative grafische Notation der Index Unit und Multichoice Index Unit RubricList in UML Notation.

Figure 16. Alternative UML-Syntax der Index Unit a) und Multichoice Index Unit b) RubricList.

Alternative UML-Syntax der Index Unit a) und Multichoice Index Unit b) RubricList.

Hierarchical Index Unit

Eine weitere Variante der zuvor erläuterten Index Unit ist die Hierarchical Index Unit. Hier werden eine Menge von Instanzen in unterschiedlichen Hierarchieebenen strukturiert. Der Unterschied besteht nun darin, dass dieser Content Unit mehrere Entitäten zugeordnet werden können. Die Hierarchie kommt dadurch Zustande, dass eine Menge von Entitäten durch Beziehungen miteinander verbunden sind. Die Beziehungsrollen können dann als Selektorbedingung verwendet werden, denn sie spiegeln die Vater-Kind Beziehung zwischen zwei Entitäten wieder und ordnen damit der übergeordneten Instanz einer Entität entsprechende zugehörige Instanzen der untergeordneten Entität zu ( [CeriFrat03] S.85). Die hierarchische Verbindung zweier Entitäten erfolgt durch das Wort NEST.

Abbildung 17 zeigt die grafische Notation einer Hierarchical Index Unit in WebML-Syntax. Entity1 repräsentiert die Instanzen der obersten Hierarchiebene und ist durch NEST und der Selektorbedingung Selector2 mit Entity2 verschachtelt. Zu einer Instanz der Entity1 werden entsprechend der Selektorbedingung Selector2 Instanzen der Entity2 zugeordnet. Eine solche Verschachtelung kann über N Stufen erfolgen.

Figure 17. Grafische Notation einer Hierarchical Index Unit in WebML Syntax.

Grafische Notation einer Hierarchical Index Unit in WebML Syntax.

Abbildung 18 zeigt ein Beispiel einer Hierarchical Index Unit RubricList mit folgenden Eigenschaften:

Nutzerdefinierter Name: RubricList
Quell-Entität1: Rubric
Quell-Entität2: Contribution
Selektor1: ohne Selektor 
Selektor2: [RubricToContribution]  Beziehung zwischen Rubric und Contribution
Zugeordnete Attribute für Entität1: rubricName
Zugeordnete Attribute für Entität2: title
Sortierbedingung1: rubricName
Sortierbedingung2: title

Die Hierarchical Index Unit RubricList ist in zwei Hierarchieebenen strukuriert. Die oberste Ebene wird durch die Entität Rubric repräsentiert. Da für Rubric kein Selektor definiert wurde, werden alle Rubriken mit ihrem Attribut rubricName aufgelistet. Über die Verbindung NEST wird die zweite zugeordnete Entität Contribution mit Rubric verschachtelt. Rubric und Contribution sind über eine Beziehungsrolle RubricToContribution miteinander verbunden. Der Selektor2 der Entität Contribution ordnet damit jeder aufgelisteten Instanz von Rubric die ihr über diese Beziehung zugeordneten Instanzen von Contribution zu. Jeder Rubrik sind beliebig Beiträge zugeordnet, und jeder Beitrag gehört zu genau einer Rubrik. Erstere Aussage wird durch die Hierarchical Index Unit RubricList ausgedrückt. ( [CeriFrat03] S.85 ff.)

Figure 18. Grafische Notation der Hierarchical Index Unit RubricList mit zugehörigen Entitäten.

Grafische Notation der Hierarchical Index Unit RubricList mit zugehörigen Entitäten.

Textuelle Notation der Hierarchical Index Unit aus Abbildung 18:

IndexUnit RubricList hierarchical
(source Rubric;
 attributes rubricName;
 orderby rubricName
 NEST Contribution;
 selector RubricToContribution;
 attributes title;
 orderby title)

Abbildung 19 stellt die alternative UML-Syntax der grafischen Notation einer Hierarchical Index Unit allgemein, sowie der Hierarchical Index Unit RubricList aus Abbildung 18 dar. Diese Notation ist im Vergleich zur WebML-Syntax einer Hierarchical Index Unit sehr komplex, da alle zugeordneten Entitäten in die grafische Notation mit eingebunden werden.

Figure 19. Alternative UML-Syntax einer Hierarchical Index Unit allgemein und speziell für die Hierarchical Index Unit RubricList.

Alternative UML-Syntax einer Hierarchical Index Unit allgemein und speziell für die Hierarchical Index Unit RubricList.

Scroller Unit

Eine Scroller Unit bietet die Möglichkeit, durch eine Menge von Instanzen zu blättern. Sie wird üblicherweise in Verbindung mit einer Data Unit verwendet, die dann die Daten der gewünschten Instanz darstellt. Sie kann jedoch auch mit allen anderen informationsdarstellenden Content Units verbunden werden. Eine Scroller Unit wird zusätzlich durch einen Blockfaktor beschrieben und im Gegensatz zu den bisherigen Content Units werden keine Attribute zugeordnet . Der Blockfaktor gibt die Anzahl der Instanzen an, die gleichzeitig durchblättert bzw. angezeigt werden. Als Defaultwert gilt der Blockfaktor 1. Abbildung 20 zeigt eine Scroller Unit gemeinsam mit der Data Unit AuthorInfo aus Abbildung 11 mit folgenen Eigenschaften:

Nutzerdefinierter Name: AuthorScroll
Quell-Entität: Author
Selektor: ohne Selektor 
Blockfaktor:1
Sortierbedingung:lastname, firstname (ascending als Default)

Figure 20. Grafische Notation der Scroller Unit AuthorScroll in Verbindung mit der DataUnit AuthorInfo, in WebML Syntax.

Grafische Notation der Scroller Unit AuthorScroll in Verbindung mit der DataUnit AuthorInfo, in WebML Syntax.

Die Scroller Unit AuthorScroll ist über der Entität Author definiert und ermöglicht es, durch alle Instanzen dieser Entität zu blättern, da kein Selektor definiert ist. Um auch die entsprechenden Daten der aktuell ausgewählten Instanz anzuzeigen, ist die Scroller Unit mit der Data Unit AuthorInfo über einen Link verbunden. Für jede Instanz werden die Informationen firstname, lastname, email, und photo durch die Data Unit dargestellt. Die Sortierbedingung mit Angabe der zwei Attribute lastname und fistname bedeutet, dass zuerst nach lastname sortiert wird und, sofern zwei gleiche Werte auftreten, zusätzlich firstname als Kriterium hinzugezogen wird. In der textuellen Notation einer Scroller Unit sind wiederum die nicht aus der grafischen Notation ersichtlichen Eigenschaften vorhanden. ( [CeriFrat03] S.88 f.)

Textuelle Notation der Scroller Unit aus Abbildung 20:

ScrollerUnit AuthorScroll
(source Author;
 blockFactor 1;
 orderby lastname, firstname)

Abbildung 21 zeigt die grafische Notation einer Scroller Unit allgemein, sowie das Beispiel aus Abbildung 20 in UML-Syntax. Die Scroller Unit sowie die Data Unit sind beide über der Entität Author definiert und über einen Link miteinander verbunden.

Figure 21. Alternative UML-Syntax einer Scroller Unit allgemein und speziell für die Scroller Unit AuthorScroll zusammen mit Data Unit AuthorInfo.

Alternative UML-Syntax einer Scroller Unit allgemein und speziell für die Scroller Unit AuthorScroll zusammen mit Data Unit AuthorInfo.

Entry Unit

Eine Entry Unit dient der Aufnahme von Informationen durch Nutzereingaben in definierte Eingabefelder, um diese Parameter dann an entsprechende Operationen weiterzuleiten. Entry Units ermöglichen damit die Suche nach Instanzen einer Entität, die Verwaltung von Daten oder die Nutzung von Funktionen wie Login durch die Eingabe und Auswertung entsprechender Parameter. Entry Units werden durch einen nutzerdefinierten Namen und einer Menge von Eingabefeldern beschrieben. Die Eingabefelder werden durch einen Namen, einen Datentyp, einen optionalen Initialwert, sowie durch eine Gültigkeitsbedingung definiert. Eine Gültigkeitsbedingung kann jeder logische Ausdruck sein, der den jeweiligen Feldnamen sowie Operationen verwendet, die sich auf den Wert des Feldes oder andere Felder beziehen. Das Schlüsselwort notnull wird verwendet, um die Eingabe eines Wertes für dieses Eingabefeld durch den Nutzer zu erzwingen. Abbildung 22 zeigt die grafische Notation einer Entry Unit AuthorInput mit folgenden Eigenschaften:

Nutzerdefinierter Name: AuthorInput
Eingabefelder: LastnameFirstnameEmailBiography

Feldname1: Lastname
Datentyp: string
Initialwert: keine Angabe
Gültigkeitsbedingung: notnull

Feldname2: Firstname
Datentyp:string
Initialwert: keine Angabe
Gültigkeitsbedingung: notnull

Feldname3: Email
Datentyp: string
Initialwert: keine Angabe
Gültigkeitsbedingung: notnull

Feldname4: Biography
Datentyp:text
Initialwert: keine Angabe
Gültigkeitsbedingung: keine Angabe

Figure 22. Grafische Notation der Entry Unit AuthorInput in WebML Syntax.

Grafische Notation der Entry Unit AuthorInput in WebML Syntax.

In der grafischen Notation sind keine Informationen über die Eigenschaften der einzelnen Eingabefelder enthalten. Diese sind nur aus der textuellen Notation einer Entry Unit ersichtlich. Die Definition einer Entry Unit wird durch das Element EntryUnit eingeleitet, in dem anschließend die einzelnen Eingabefelder (fields) und ihre Eigenschaften definiert werden. ([CeriFrat03] S.89 f.)

Textuelle Notation der Entry Unit aus Abbildung 22:

EntryUnit AuthorInput
(fields
 Firstname string, notnull;
 Lastname string, notnull;
 Email string, notnull;
 Biography text)

Abbildung 23 zeigt die alternative grafische Darstellung einer Entry Unit allgemein und die Entry Unit AuthorInput aus Abbildung 22 in UML-Syntax.

Figure 23. Alternative UML-Syntax einer Entry Unit allgemein und speziell für die Entry Unit AuthorInput.

Alternative UML-Syntax einer Entry Unit allgemein und speziell für die Entry Unit AuthorInput.

Zusammenfassung

Die zwei vorgestellten grafischen Notationsmöglichkeiten in WebML-Syntax und UML-Syntax sind für den Entwurf des Hypertextmodells gleichermassen einsetzbar. Die Darstellung der Content Units in UML-Syntax enthält wesentlich mehr Informationen als die grafische Darstellung in WebML-Syntax. Dennoch ist der Einsatz der WebML-Syntax empfehlenswerter, da zum einen die fehlenden Informationen aus der textuellen Notation ersichtlich sind, und zum anderen das Hypertextmodell durch die einfachere grafische Notation wesentlich übersichtlicher bleibt. In WebRatio ist für den Entwurf des Hypertextmodells ausschließlich die WebML–Syntax vorgesehen. Aus diesen Gründen wird diese Notation auch im Verlauf dieser Arbeit und bei der Umsetzung des Projektes verwendet.

Navigationsmodell

Um einen kompletten Hypertext zu modellieren, müssen zusätzlich zum Kompositionsmodell und seinen Elementen weitere Konzepte hinzugefügt werden. Diese Konzepte dienen der Verknüpfung einzelner Content Units und Pages, um die Navigation zwischen Pages zu ermöglichen, sowie Interaktionen des Nutzers mit der Anwendung und der durch sie präsentierten Daten zu beschreiben. Erst die Kombination von Kompositionsmodell und Navigationsmodell ermöglicht den vollständigen Entwurf eines Hypertextes. Die wichtigsten Konzepte der Navigationsmodellierung sind Links, Linkparameter und parametrische Selektoren. Ein Link ist eine gerichtete Verbindung zwischen zwei Content Units oder Pages, über die Informationen, die sogenannten Linkparameter, übertragen werden können. Ein parametrischer Selektor ist ein Selektor einer Content Unit, der zur Bestimmung des Inhalts einer Content Unit übertragende Linkparameter verwendet. Im Laufe des Kapitels werden diese Konzepte näher erläutert.

Arten von Links

Links erlauben zum einen die Navigation zwischen verschiedenen Pages oder Content Units, und zum anderen den Transport von Informationen zwischen zwei Units. In WebML werden bezüglich dieser Eigenschaften verschiedene Arten von Links unterschieden. Links, die zwei Pages oder Content Units verschiedener Pages verbinden, werden inter-page Links genannt. Links, die zwei Content Units innerhalb der gleichen Page verbinden, werden intra-page Links genannt. Ein Link wird allgemein definiert durch folgende Eigenschaften:

  • Nutzerdefinierter Name

  • Quelle

  • Ziel

  • Linkparameter

Kontextunabhängige Links

Kontextunabhängige Links sind Verknüpfungen, über die keine Informationen transportiert werden. Sie dienen nur der Navigation eines Nutzers zwischen inhaltlich nicht aufeinander bezogenen Pages. Links werden grafisch durch gerichtete Pfeile von der Quelle zum Ziel dargestellt.

Abbildung 24 stellt ein Beispiel eines kontextunabhängigen Links dar. Die hier dargestellte Area Contributions enthält die Page ByRubric, zur Auflistung der Rubriken eines Journals, und die Page AllTopics, zur Auflistung aller Themengebiete des Journals. Die Area ist durch die Markierung als landmark von allen anderen Areas und Pages der übergeordneten Hypertext View erreichbar. Nach dem Zugriff auf Contributions wird zunächst die als default gekennzeichnete Page ByRubric dem Nutzer präsentiert. Über einen für den Nutzer sichtbaren Link GoToTopics kann dieser von Page ByRubric zur Page AllTopics wechseln. Es handelt sich hierbei um einen einfachen Wechsel von einer Page zu einer anderen, ohne das Informationen übertragen werden.

Figure 24. Beispiel eines kontextunabhängigen Links.

Beispiel eines kontextunabhängigen Links.

Auch für die Definition von Links wird von WebML eine textuelle Notation zur Verfügung gestellt. Die Definiton eines Links erfolgt durch das Element link und der Angabe der Quelle (from) und des Ziels (to).

Textuelle Notation des kontextunabhängigen Links aus Abbildung 24:

link GoToTopics
(from ByRubric to AllTopics)

Kontextabhängige Links

Kontextabhängige Links sind Verknüpfungen von Content Units innerhalb einer Page oder verschiedener Pages, die dabei Informationen übertragen. Die präsentierten Daten einer Content Unit sind somit abhängig von den Linkparametern der eingehenden Verknüpfung. Kontextabhängige Links werden, entsprechend der Art und Weise der Informationsübertragung, in drei Arten unterteilt. ( [CeriFrat03] S.92 ff.)

  • einfache kontextabhängige Links

    Einfache kontextabhängige Links übertragen Informationen zwischen Content Units und ermöglichen ausserdem die gleichzeitige Navigation zwischen Pages, nach Ausführung einer entsprechenden Nutzerinteraktion. Abbildung 25 zeigt ein Beispiel für einfache kontextabhängie Links.

    Die Area Contributions enthält die Pages ByRubric und RubricContributions. ByRubric enthält eine Index Unit AllRubrics zur Auflistung aller Rubriken eines Journals. RubricContributions enthält eine Data Unit RubricDetails zur Darstellung von Detailinfomationen einer Rubrik, und eine Index Unit ContributionList zur Auflistung von Beiträgen einer bestimmten Rubrik. Dem Nutzer wird zunächst die Page ByRubric angezeigt, und damit eine Liste aller Rubriken in Form von auswählbaren Einträgen. Erst nach Auswahl eines Eintrags wird über den Link ToDetails zwischen AllRubrics und RubricDetails Information übertragen. Gleichzeitig erfolgt der Wechsel zur Page RubricDetails. Auf dieser Page werden nun Detailinformationen der zuvor ausgewählten Rubik angezeigt. Nach Betätigung eines weiteren Links showContributions zwischen RubricDetails und ContributionList, werden dem Nutzer die der Rubrik zugeordneten Beiträge angezeigt. Dies erfolgt, indem der Selektor [RubricToContribution(para)] der Index Unit den übertragenden Linkparameter para auswertet. Die Informationsübertragung und Informationsdarstellung erfolgt sozusagen nur nach einer entsprechenden Aktion des Nutzers.

    Figure 25. Beispiel einfacher kontextabhängiger Links.

    Beispiel einfacher kontextabhängiger Links.
  • Automatische kontextabhängige Links

    Ein automatischer kontextabhängiger Link (automatic link) stellt eine Erweiterung eines einfachen kontextabhängigen Links dar. Ein automatischer Link überträgt Informationen an eine weitere Content Unit, sobald auf die Page zugegriffen wird, sozusagen ohne die Ausführung des Links durch den Nutzer. Automatische kontextabhängige Links können nur für Index Units, Hierarchical Index Units, Multichoice Index Units und Scroller Units definiert werden, da nur diese Content Units dem Nutzer ermöglichen, eine Instanz aus einer Menge von Instanzen auszuwählen. Ein automatischer Link wird in der grafischen Notation durch einen gerichteten Pfeil mit einem "A"gekennzeichnet. In der textuellen Notation wird für die Definition eines automatischen Links das Wort automatic hinzugefügt. Zur Verdeutlichung der Funktion von automatischen Links dient das Beispiel in Abbildung 26.

    Die Page AllTopics enthält eine Index Unit Topics, eine Data Unit TopicDetails und eine weitere Index Unit ContributionList. Nach dem Zugriff auf die Page wird eine Liste aller Themengebiete angezeigt, sowie bereits vorausgewählte Detailinformationen zu einem Thema. Die Weiterleitung des entsprechenden Linkparameters über den Link ToDetails erfolgt automatisch beim Zugriff auf die Page. Im Unterschied zu einfachen kontextabhängigen Links wird hier eine Instanz vorausgewählt, um Daten bereits vor der Auswahl eines Eintrags durch den Nutzer anzuzeigen. Üblicherweise werden die Daten des ersten Eintrags der Liste angezeigt. Durch weitere Interaktionen des Nutzers ändern sich die Inhalte der Data Unit. Durch die Betätigung eines weiteren Links showContributions, werden die zu diesem Thema vorhanden Beiträge durch die Index Unit ContributionList dem Nutzer präsentiert. Dies erfolgt durch die Auswertung des Linkparameters para im parametrischen Selektor [TopicToContribution(para)] von ContributionList.

    Figure 26. Beispiel eines automatischen kontextabhängigen Links.

    Beispiel eines automatischen kontextabhängigen Links.
  • Transportierende kontextabhängige Links

    Transportierende kontextabhängige Links (transport link) dienen nur dem Transport von Informationen, nicht aber der Interaktion eines Nutzers mit der Anwendung. Transportierende Links werden sozusagen nicht als sichtbare Links gekennzeichnet. Sie sorgen dafür, dass aufeinander bezogene Content Units sofort Inhalte zugewiesen bekommen und entsprechend anzeigen, ohne die Betätigung eines Links durch den Nutzer. Ein transportierender Link wird in der grafischen Notation durch einen gestrichelten Pfeil gekennzeichnet. In der textuellen Notation wird zu der Definition eines transportierendenLinks das Wort transport hinzugefügt. ([CeriFrat03] S. 104 ff.) Um die Funktion eines transportierenden Links zu verdeutlichen wird das Beispiel aus Abbildung 26 leicht abgewandelt.

    Nach dem Zugriff auf die Area Contributions wird dem Nutzer die default Page ByRubric angezeigt. Nach der Auswahl eines Eintrags aus der angezeigten Liste der Rubriken, wechselt die Ansicht nun zur Page RubricContributions. Dem Nutzer werden nun Detailinformationen zur ausgewählten Rubrik und gleichzeitig eine Liste aller der Rubrik zugeordeten Beiträge präsentiert. Der Unterschied zum Beispiel aus Abbildung 26 besteht nun darin, dass die Zuordnung und Anzeige aller Beiträge der Rubrik ohne die Betätigung eines extra Links erfolgt. Die Data Unit und Index Unit präsentieren gleichzeitig ihren Inhalt.

    Figure 27. Beispiel eines transportierenden Links.

    Beispiel eines transportierenden Links.
Linkparameter und parametrische Selektoren

In diesem Kapitel werden Linkparameter und parametrische Selektoren der verschiedenen Content Units näher erläutert. Die Verknüpfung zweier Units wird durch die übertragenen Linkparameter und den parametrischen Selektoren in der Ziel Unit beschrieben. Ein Linkparameter besteht aus einem nutzerdefinierten Namen und dem Namen des Attributes oder Feldes, dessen Inhalt über den Link transportiert wird, getrennt durch einen Doppelpunkt. Der nutzerdefinierte Name des Linkparameters kann im Selektor der Ziel Unit als Referenz zur Berechnung des Inhalts verwendet werden. Die Darstellung des transportierenden Attributwertes erfolgt durch das Hinzufügen der zugehörigen Entität zum Namen des Attributes, getrennt durch einen Punkt in der Form: SourceEntity. attributName. ([CeriFrat03] S.94 f. ) Die Defintion der Linkparameter kann zur grafischen Notation, sowie zur textuellen Notation hinzugefügt werden.

Abbildung [28] zeigt die grafische Notation eines einfachen kontextabhängigen Links mit ausführlicher Notation des Linkparameters und parametrischen Selektor. Nach Auswahl eines Eintrags aus der Index Unit AllRubrics, wird die eindeutige ObjekID der ausgewählten Instanz der Entität Rubric (Rubric.OID) übertragen. Der nutzerdefinierte Name ist ActRubric und dient als Referenz für den Wert des Attributes OID zur Berechnung des Inhalts in der Data Unit RubricDetails. Durch den Selektor [OID=ActRubric] wird die Detailinformation der Instanz, mit der OID des übertragenden Parameters, angezeigt.

Figure 28. Linkparameter und parametrischer Selektor eines einfachen kontextabhängigen Links.

Linkparameter und parametrischer Selektor eines einfachen kontextabhängigen Links.

Textuelle Notation des kontextabhängigen Links aus Abbildung 28 mit Definition 
des Linkparameters (parameters):

link To RubricDetails
(from AllRubrics to RubricDetails
 parameters ActRubric:Rubric.OID)

Einwertige und mehrwertige Linkparameter

Linkparameter können einwertig und mehrwertig sein, je nach Typ der Quell Unit. Der Linkparameter eines ausgehenden Links einer Data Unit kann nur einwertig sein, da nur eine Instanz mit der Data Unit dargestellt werden kann. Linkparameter eines ausgehenden Links von Index Units und Hierarchical Index Units sind ebenfalls einwertig, denn sie ermöglichen die Auswahl immer nur einer Instanz aus einer Liste, dessen OID dann zu einer anderen Content Unit übertragen wird. Linkparameter des ausgehenden Links von Multichoice Index Units können dagegen mehrwertig sein, denn sie ermöglichen die Auswahl einer Menge von Instanzen, deren OIDs dann gemeinsam übertragen werden. Linkparameter ausgehender Links von Multidata Units müssen mehrwertig sein, denn sie ermöglichen nur die Übertragung von Attributen aller in der Menge enthaltenen Instanzen. Die Wertigkeit des ausgehenden Links einer Scroller Unit ist abhängig vom definierten Block Faktor. Dieser bestimmt die Menge der Instanzen, für die entsprechende OIDs übertragen werden. ([CeriFrat03] S.96 ff. ) Ein mehrwertiger Linkparameter wird durch die Umschließung des Attributnamens mit geschwungenen Klammern gekennzeichnet, in der Form:

userdefinedName:{SourceEntity.attributeName}

Abbildung 29 zeigt ein Beispiel eines mehrwertigen Linkparameters anhand einer Mutichoice Index Unit AuthorList und einer Multidata Unit SelectedAuthors. Durch die Multichoice Index Unit ist es möglich mehrere Instanzen der Entität Author auszuwählen, deren OIDs durch den mehrwertigen Linkparameter SelAuthors übertragen werden. Durch die Multidata Unit SelectedAuthors werden nur die durch den Selektor [OID IN SelAuthors] bestimmten Instanzen angezeigt. Es werden alle Instanzen dargestellt, deren OID durch SelAuthors übertragen wurden.

Figure 29. Grafische Notation eines mehrwertigen Linkparameters.

Grafische Notation eines mehrwertigen Linkparameters.

Textuelle Notation des Links aus Abbildung 29 mit mehrwertigen Linkparameter:

link ToSelectedAuthors
(from AuthorList to SelectedAuthors
 parameters SelAuthors:{Author.OID})

Linkparameter können auch für Entry Units definiert werden, um die Werte der Eingabefelder zu übertragen. Im Unterschied zu den anderen Content Units besteht der Linkparameter einer Entry Unit aus einem nutzerdefinierten Namen und dem Namen des Eingabefeldes, dessen Wert übertragen werden soll. Abbildung 30 zeigt das Beispiel einer Entry Unit ByTitle zur Suche nach bestimmten Beiträgen mit folgenden Eigenschaften:

Nutzerdefinierter Name: ByTitle
Eingabefelder: TitleDate

Feldname1: Title
Datentyp: string
Gültigkeitsbedingung: notnull

Feldname2: Date
Datentyp: Date

Die Entry Unit ByTitle ermöglicht die Suche nach Beiträgen mit einem bestimmten Titel oder Titelbestandteil und optional durch die Angabe eines Datums. Durch die zwei Linkparameter SearchTitle und SearchDate werden die Werte des jeweilgen Eingabefeldes übertragen und durch die Selektoren [title contains SearchTitle], [date > SearchDate] der Index Unit ContributionList ausgewertet. Es werden alle Beiträge aufgelistet, deren Titel den Wert in SearchTitle enthält und deren Datum größer als SearchDate ist. Das Schlüsselwort implied bedeutet, dass bei fehlender Angabe eines Wertes für das entsprechende Eingabefeld oder Attribut, die Auswertung des jeweiligen Linkparameters ignoriert wird. In diesem Beispiel kann die Angabe eines Datums bei der Suche nach bestimmten Beiträgen weggelassen werden. Der Selektor wird dann so ausgeführt, als wäre die Bedingung für den Linkparameter SearchDate nicht definiert.

Figure 30. Beispiel für Linkparameter des ausgehenden Links der Entry Unit ByTitle.

Beispiel für Linkparameter des ausgehenden Links der Entry Unit ByTitle.

Textuelle Notation des Links showContributions aus Abbildung 30:

link showContributions
(from ByTitle to ContributionList
 parameters SearchTitle:Title, SearchDate:Date)

Globale Parameter

Globale Parameter ermöglichen den globalen Zugriff auf Informationen, ausgehend von allen Pages einer Hypertext View, das heisst ohne die Navigation zwischen zwei Content Units durch entsprechende Links. Global abgelegte Infomationen sind somit jeder Content Unit zugänglich. Die Nutzung dieses Konzeptes erfordert die Deklararion eines globalen Parameters mit folgenden Eigenschaften:

  • Nutzerdefinierter Name

  • Typdefinition des Parameters

  • Optionaler Default Wert, mit dem der Parameter initialisiert wird

Ein Beispiel für die Verwendung eines globalen Parameters ist die Speicherung der OID des aktuell eingeloggten Nutzers. Damit ist es nun möglich, nutzerbezogenen Inhalt durch jede Content Unit der Hypertext View zu erzeugen, die diesen Parameter benötigt. Normalerweise erfolgt die Übertragung solcher Informationen über explizit definierte Links zwischen Content Units. Die Speicherung und Abfrage globaler Parameter erfolgt über sogenannte Set Units und Get Units. Folgende textuelle Notation beschreibt die Defintion eines globalen Parameters CurrentUser:

globalParameter CurrentUser
(type OID;
 entity User)

Set Unit

Bevor der Wert eines globalen Parameters durch eine Content Unit verwendet werden kann, muss dieser gespeichert werden. Die Speicherung eines Wertes erfolgt durch eine Set Unit vom Typ des zu speichernden globalen Parameters, die im Hypertextmodell ausserhalb von Pages platziert wird. Eine Set Unit besitzt einen einzigen eingehenden transportierenden Link, dessen Linkparameter den im globalen Parameter abzuspeichernden Wert überträgt.

Abbildung 31 zeigt ein Beispiel für die Abspeicherung der OID eines Nutzers durch die Set Unit Set User vom Typ des globalen Parameters CurrentUser. Die abzuspeichernde OID des Nutzers wird über den transportierenden Link zwischen Data Unit User data und Set Unit Set User übertragen.

Figure 31. Grafische Notation einer Set Unit.

Grafische Notation einer Set Unit.

Textuelle Notation der Set Unit Set User und des transportierenden Links aus Abbildung 31:

link UserdataToSetUser transport
(from User data  to Set User)

setUnit Set User
(parameter CurrentUser)

Get Unit

Nachdem der Wert des globalen Parameters gesetzt wurde, kann dieser durch eine Get Unit abgerufen werden. Eine Get Unit wird innerhalb der Page platziert, in der der globale Parameter von einer Content Unit benötigt wird. Eine Get Unit hat im Gegensatz zur Set Unit einen einzigen ausgehenden Ttransportierenden Link, dessen Linkparameter den abgespeicherten Wert an die entsprechende Content Unit überträgt.

Folgende Abbildung 32 zeigt die Verwendung einer Get Unit, um persönliche Daten eines Nutzers anzuzeigen. Die Index Unit my submit contributions benötigt für ihren Selektor [AuthorToContribution_submit] die OID des aktuellen Nutzers, in diesem Beispiel des eingeloggten Autors. Die OID wird über die Get Unit Get User über den transportierenden Link an die Index Unit übergeben. Die Selektorbedingung kann nun für diese OID die Beziehungsrolle AuthorToContribution_submit auswerten, die einem Autor alle seine eingestellten Beiträge zuordnet.

Figure 32. Grafische Notation einer Get Unit.

Grafische Notation einer Get Unit.

Textuelle Notation der Get Unit Get User und des transportierenden Links aus Abbildung 32:

link GetUserToMysubContr transport
(from Get User to my submit contributions)

getUnit Get User
(parameter CurrentUser)

Werte globaler Parameter beziehen sich immer auf genau eine Nutzer-Session, so dass verschiedene Nutzer auch unterschiedliche Werte eines globalen Parameter besitzen können.

Content Management Modell

Der Hypertextentwurf einer komplexen Webanwendung umfasst nicht nur die strukturierte Darstellung von Informationen durch die Kombination von Content Units und Verknüpfung mit Links. Ein wichtiger Aspekt beim Entwurf des Hypertextes und damit bei der Umsetzung webspezifischer Gesichtspunkte, ist die Einbindung von speziellen Content Management Operationen, um die Daten der Webanwendung zu verändern. Das in Kapitel 4.3 beschriebene Hypertextmodell wird durch entsprechende Operation Units erweitert, die diese Funktionalität der Datenmanipulation bereitstellen. Das Content Management Modell stellt damit kein eigenständiges Modell dar, wie das Informationsmodell oder Hypertextmodell, sondern beschreibt notwendige Operation Units und ihre Verknüpfung mit entsprechenden Content Units. Typische Operationen sind dIe Erzeugung, die Aktualisierung und das Löschen von Daten bzw. Objekten. Diese werden durch vordefinierte Operationen mit speziellen Ausgangslinks durch WebML zur Verfügung gestellt. Zur Unterstützung der Personalisierung einer Webanwendung dienen Operation Units in Form von Login Units und Logout Units, die eine gewünschte Zugriffskontrolle entsprechend definierter Nutzergruppen auf die Anwendung ermöglichen.

Operation Units werden ausserhalb von Pages platziert und können mit weiteren Operation Units oder Content Units innerhalb einer Page verbunden sein. Sie dienen dabei nicht der Darstellung von Informationen, sondern haben die Aufgabe, definierte Aktionen auszuführen. Operation Units besitzen ebenso wie Content Units eine Quell-Entität oder. beziehen sich auf eine Relation zwischen zwei Entitäten. Es können zusätzlich Selektoren definiert werden, um eine Aktion nur auf bestimmte Objekte anzuwenden. Eine Operation Unit kann mehrere eingehende und mehrere ausgehende Links besitzen, über die Linkparameter transportiert werden. Zur Aktivierung einer Operation dient ein einfacher kontextabhängiger Link. Jede Operation Unit besitzt zusätzlich 2 spezielle Ausgangslinks, einen OK-link sowie einen KO-link.

Das Ziel eines OK-links wird erreicht, wenn die zugehörige Operation erfolgreich ausgeführt wurde. Das Ziel des KO-links wird dagegen erreicht, wenn die Operation nicht erfolgreich ausgeführt werden konnte. Entsprechend dieser Eigenschaften kann die Reaktion der Anwendung auf ausgeführte Operationen bestimmt werden. Durch die Verknüpfung mehrerer Operation Units durch ihre ausgehenden OK-links kann eine Sequenz von Operationen erreicht werden, die nacheinander ausgeführt werden sollen.

In den folgenden Kapiteln werden nun die grundlegenden Konzepte der Content Management Modellierung erläutert. Dabei wird auf folgende Elemente eingegangen:

  • Create Unit

  • Delete Unit

  • Modify Unit

  • Connect Unit

  • Disconnect Unit

  • Transactions

  • Login Unit

  • Logout Unit

Create Unit

Eine Create Unit dient der Erzeugung eines neuen Objektes der ihr zugewiesenen Quell-Entität. Typischerweise ist eine Create Unit mit einer Entry Unit verknüpft. Die Create Unit benutzt die über den eingehenden Link übertragenen Werte der Eingabefelder bei der Erzeugung des Objektes durch entsprechend festgelegte Verknüpfungen. Die Ausgabe einer Create Unit nach einer erfolgreich ausgeführten Create-Operation sind die Attributwerte des neu erzeugten Objektes, die dann als Linkparameter eines ausgehenden transportiernenden Links oder des OK-links verwendet werden können. Werden keine Linkparameter für die ausgehenden Links definiert, wird standardmässig die OID des erzeugten Objektes übertragen. Folgendes Beispiel ist ein Ausschnitt aus dem Hypertextmodell des Beispielprojektes dieser Arbeit "Entwurf eines wissenschaftlichen Online Journals" und soll die Verwendung einer Create Unit verdeutlichen.

Ziel dieses Beispiels ist das Anlegen einer neuen Ausgabe des Journals. Abbildung 33 zeigt die Page Create new issue mit der Entry Unit new issue data, sowie die Page Modify selected issue mit einer Data Unit selected issue und einer weiteren Entry Unit change issue data. Die Content Units sowie die Create Unit besitzen folgende Eigenschaften:

Data Unit

Nutzerdefinierter Name: selected issue
Quell-Entität: Issue
Selektor: default
Zugeordnete Attribute: (volume, number, title, description).

Entry Units

Nutzerdefinierter Name: new issue data / change issue data
Eingabefelder: VolumeNumberIssue titleDescription

Feldname1: Volume
Datentyp: number
Initialwert: keine Angabe
Gültigkeitsbedingung: notnull

Feldname2: Number
Datentyp: number
Initialwert: keine Angabe
Gültigkeitsbedingung: notnull

Feldname3: Issue title
Datentyp: string
Initialwert: keine Angabe
Gültigkeitsbedingung: keine Angabe

Feldname4: Description
Datentyp: text
Initialwert: keine Angabe
Gültigkeitsbedingung: keine Angabe

Create Unit 

Nutzerdefinierter Name: CreateIssue 
Quell-Entität: Issue
Spezielle Verknüpfungen: 
volume=Vol, number=Num, title=Title, description=Desc, status="new"

Verknüpfung der Linkparameter des eingehenen Links oder eines konstanten Wertes 
(Vol, Num, Title, Desc) mit den Attributen des zu erzeugenden Objektes 
(volume, number,title, description, status)

Figure 33. Grafische Darstellung einer Create Unit in Verbindung mit einer Entry Unit und Data Unit.

Grafische Darstellung einer Create Unit in Verbindung mit einer Entry Unit und Data Unit.

Die Werte der Eingabefelder der Entry Unit new issue data werden über den Link toCreateIssue zur Create Unit CreateIssue übertragen. Die Aktivierung der Create Operation erfolgt also erst nach Betätigung dieses Links. Die Create Unit ist der Entität Issue aus dem Informationsmodell zugeordnet, welche ebenfalls in Abbildung 33 zu sehen ist. Über definierte Verknüpfungen volume =Vol, number =Num, title =Title, description =Desc, status="new" werden den Attributen des zu erzeugenden Objektes die Werte der Eingabefelder zugewiesen. Das Attribut status erhält dabei einen konstanten Wert "new", der diese Journalausgabe als neu angelegte Ausgabe kenntlich macht. Bei erfolgreicher Ausführung der Operation wird die OID des erzeugten Objektes über den definierten OK-link zur Data Unit selected issue übertragen. Diese präsentiert nun die gewünschten Attributwerte des neu erzeugten Objektes. Über die Entry Unit change issue data können die Daten der neu erzeugten Ausgabe geändert werden, indem diese mit einer Modify Unit verbunden wird. Die Erweiterung dieses Beispiels zur Erläuterung der Änderung von Daten erfolgt in Kapitel 4.4.3.([CeriFrat03] S.137 ff.)

Die Deklaration einer Create Unit erfolgt in textueller Notation durch das Schlüsselwort CreateUnit. Es folgen der nutzerdefinierte Name, die Angabe der Quell-Entität, sowie die definierten Verknüpfungen mit entsprechenden Linkparametern eingehender Links. Folgender Codeausschnitt zeigt die textuelle Notation der Create Unit CreateIssue und des Links toCreateIssue aus Abbilldung 33:

CreateUnit CreateIssue
(source Issue;
 volume:=Vol, number:=Num, title:=Title, description:= Desc)

link toCreateIssue
(from new issue data   to CreateIssue;
 parameters Vol:Volume, Num:Number, Title:Issue title, Desc:Description)

Delete Unit

Eine Delete Unit dient dem Löschen eines ganz bestimmten Objektes oder einer Menge von Objekten. Sie wird definiert durch einen nutzerdefinierten Namen, die Zuordnung einer Quell-Entität, sowie die Defintion eines Selektors zur Bestimmung des zu löschenden Objektes oder der zu löschenden Objektmenge.

Folgendes Beispiel in Abbildung 34 soll die Verwendung einer Delete Unit verdeutlichen. Hierbei handelt es sich wieder um einen Ausschnitt des Beispielprojektes dieser Arbeit. Ein Redakteur des Journals hat die Möglichkeit, zu einem Beitrag ein oder mehrere Gutachten vorzubereiten. Jedes Gutachten wird dabei genau einem Gutachter zugewiesen. Die Abbildung zeigt die Page first Contributions mit einer Data Unit Contribution Details und einer Index Unit prepared Reviews, sowie eine Delete Unit DeleteReview mit folgenden Eigenschaften:

Data Unit

Nutzerdefinierter Name: Contribution Details
Quell-Entität: Contribution
Selektor: default
Zugeordnete Attribute: (title, date, submitDate, file, comment, rubric, status)

Index Unit

Nutzerdefinierter Name: prepared Reviews
Quell-Entität: Review
Selektor: [ContributionToReview]
Zugeordnete Attribute: reviewName, reviewer
Sortierbedingung: reviewName (ascending als Default)

Delete Unit

nutzerdefinierter Name: DeleteReview
Quell-Entität: Review
Selektor: default

Die Index Unit prepared Reviews listet alle vorbereiteten Gutachten des zugeordneten Beitrags auf. Dies erfolgt durch die Auswertung des Selektors [ContributionToReview], der durch den transportierenden Link zwischen der Data Unit und der Index Unit die OID des dargestellten Beitrags erhält. Die Übertragung der OID erfolgt standardmässig, sodass nicht explizit ein Linkparameter definiert werden muss. Für jeden Eintrag der Index Unit sind drei ausgehende einfache kontextabhängige Links definiert. Der Link modify führt zu einer weiteren Page zur Bearbeitung des jeweiligen Gutachtens. Der Link Details führt zu einer Page zur Anzeige von Detailinformationen des angelegten Gutachtens. Bei Ausführung des Links delete wird die Delete Unit DeleteReview aktiviert. Über den Linkparameter SelReview wird die OID des ausgewählten Gutachtens an die Delete Unit übertragen. Für die Delete Unit ist kein Selektor definiert, daher wird der Default-Selektor [OID = SelReview] ausgewertet, der die übertragene OID des Beitrags der Delete Unit zuweist. Bestehen Beziehungen zwischen dem zu löschenden Objekt der Entität Review und weiteren Objekten anderer Entitäten, so werden die Beziehungsobjekte, an denen das zu löschende Objekt beteiligt ist, ebenfalls gelöscht. In diesem Beispiel wird automatisch das Beziehungsobjekt der Beziehungsrolle ReviewToReviewer und der Beziehungsrolle ReviewToContribution entfernt. Abbildung 35 zeigt einen Ausschnitt aus dem Informationsmodell des Online Journals um den Zusammenhang zu verdeutlichen.

Figure 34. Grafische Darstellung zur Anwendung einer Delete Unit.

Grafische Darstellung zur Anwendung einer Delete Unit.

Figure 35. Ausschnitt aus Informationsmodell mit den Entitäten Contribution, Review und Reviewer.

Ausschnitt aus Informationsmodell mit den Entitäten Contribution, Review und Reviewer.

Die Deklaration einer Delete Unit in textueller Notation wird durch das Schlüsselwort DeleteUnit eingeleitet. Im Folgenden wird die textuelle Notation der Delete Unit DeleteReview aus Abbildung 34 dargestellt. Da der Default-Selektor verwendet wird, ist keine Defintion eines Selektors in textueller Notation nötig.

DeleteUnit DeleteReview
(source Review;)

Modify Unit

Die Modify Unit wird verwendet, um Attributwerte eines Objektes oder einer Objektmenge zu ändern. Eine Modify Unit wird definiert durch einen nutzerdefinierten Namen, die Angabe der Quell-Entität, die Festlegung von Selektoren, sowie einer Menge von explizit definierten Verknüpfungen zwischen Linkparametern eingehender Links und den Attributen des zu ändernden Objektes. Eine Modify Unit ist ebenso wie auch eine Create Unit typischerweise mit einer Entry Unit verbunden, um so die neuen Attributwerte über entsprechende Linkparameter zu erhalten. Ausserdem benötigt eine Modify Unit immer die Zuweisung der OIDs der zu ändernden Objekte durch die Übertragung durch Linkparameter oder durch die Auswertung optional definierter Selektoren der Modify Unit. Bei erfolgreicher Anwendung der Modify Operation auf die entsprechenden Objekte wird das Ziel des OK-links erreicht, der standardmässig die OIDs der modifizierten Objekte transportiert. Der KO-link einer Modify Unit transportiert hingegen die OIDs der Objekte, deren Attributwerte nicht geändert wurden, und wird demnach nur bei Misserfolg der Modify Operation ausgeführt.

Im folgenden Beispiel wird die Abbildung 33 durch eine Modify Unit erweitert, um die Verwendung einer Modify Unit in einem komplexeren Beispiel zu verdeutlichen. Die Modify Unit hat folgende Eigenschaften:

Modify Unit

nutzerdefinierter Name: ModifyIssue
Quell-Entität: Issue
Selektor: default
spezielle Verknüpfngen: volume =Vol, number =Num, title =Title, description =Desc

Die Data Unit selected issue zeigt die Daten des zuvor ausgewählten bzw. neu erzeugten Objektes an. Über den transportierenden Link zwischen Data Unit selected issue und der Modify Unit ModifyIssue in Abbildung 36 wird die OID des angezeigten Objektes als Linkparameter transportiert. Für die Modify Unit ist kein Selektor definiert und es wird damit der Default-Selektor [OID=<linkparameter>] ausgewertet, der die OID des zu modifizierenden Objektes der Modify Unit zuweist. Die Modify Unit ModifyIssue ist ausserdem mit der Entry Unit change issue data über einen einfachen kontextabhängigen Link verbunden, durch dessen Ausführung die Modify Operation aktiviert wird. Die Werte der Eingabefelder der Entry Unit change issue data werden über entsprechende Verknüpfungen mit den Attributen des zu modifizierenden Objektes der Entität Issue verbunden, und stellen nach erfolgreicher Ausführung der Modify Operation die neuen Attributwerte des Objektes dar. Der OK-link, sowie der KO-link der Modify Unit sind mit der Data Unit selected issue der selben Page verknüpft. Bei Erfolg oder Misserfolg der Modify Operation werden die aktuellen Daten des Objektes durch diese Data Unit angezeigt.

Figure 36. Grafische Darstellung einer Modify Unit in Verbindung mit einer Entry Unit und Data Unit.

Grafische Darstellung einer Modify Unit in Verbindung mit einer Entry Unit und Data Unit.

Textuelle Notation der Modify Unit ModifyIssue aus Abbildung 36:

ModifyUnit ModifyIssue
(source Issue;
 volume:=Vol, number:=Num, title:=Title, description:= Desc)

Connect Unit

Eine Connect Unit wird verwendet, um ein oder mehrere Beziehungsobjekte zwischen zwei Entitäten zu erzeugen. Das bedeutet, dass ein Objekt der Quell-Entität mit einem oder mehreren Objekten der Ziel-Entität verknüpft wird. Dies wird durch eine bestimmte Beziehungsrolle ausgedrückt. Eine Connect Unit wird durch die Festlegung folgender Eigenschaften definiert:

  • Nutzerdefinierter Name

  • Beziehungsrolle, auf die diese Operation angewendet wird

  • Quell-Selektor, zur Bestimmung der Objekte der Quell-Entität

  • Ziel-Selektor, zur Bestimmung der Objekte der Ziel-Entität

Abbildung 37 zeigt die grafische Darstellung einer Connect Unit mit Angabe der eben genannten wichtigsten zu definierenden Eigenschaften.

Figure 37. Grafische Darstellung einer Connect Unit.

Grafische Darstellung einer Connect Unit.

Um die Anwendung einer Connect Unit zu verdeutlichen, soll weiterhin das bisher eingeführte Beispiel dienen. Es werden hierzu drei weitere Units hinzugefügt, eine Connect Unit Connect IssueToTopic, sowie zwei Multicoice Index Units select topics und as yet choosen topics mit folgenden Eigenschaften:

Connect Unit

nutzerdefinierter Name: Connect IssueToTopic
Beziehungsrolle: IssueToTopic
Quell-Selektor: [Issue.OID=SelIssue]
Ziel-Selektor: [Topic.{OID}=SelTopic]

Multichoice Index Units

nutzerdefinierter Name: select topics
Quell-Entität: Topic
Selektor: ohne Selektor
zugeordnete Attribute: topicName
Sortierbedingung: topicName (ascending als Default)

nutzerdefinierter Name: as yet choosen topics
Quell-Entität: Topic
Selektor: [IssueToTopic]
zugeordnete Attribute: topicName
Sortierbedingung: topicName (ascending als Default)

Ziel dieses Beispiels ist die Auswahl mehrerer Themengebiete, die über die Connect Unit Connect IssueToTopic einer speziellen Ausgabe zugewiesen werden sollen. Die Connect Operation wird auf die Beziehungsrolle IssueToTopic zwischen den Entitäten Issue und Topic angewendet. Ein Auszug aus dem Informationsmodell des Beispielprojektes, der diese zwei Entitäten, sowie ihre Beziehung dargestellt, wird ebenfalls in Abbildung 38 gezeigt. Die Connect Unit soll somit einer bestimmten Ausgabe ein oder mehrere entsprechend ausgewählte Themengebiete zuordnen. Die Zuweisung einer bestimmten Ausgabe erfolgt über die Definition des Quell-Selektors [Issue.OID=SelIssue], der die OID, der in der Data Unit selected issue dargestellten Ausgabe, über den Linkparameter SelIssue erhält. Die Zuweisung der in der Mutlichoice Index Unit select topics ausgewählten Themengebiete, erfolgt über die Defintion eines Ziel-Selektors [Topic.OID=SelTopic]. Dieser Selektor erhält über den mehrwertigen Linkparameter SelTopic die OIDs der ausgewählten Themengebiete. Entsprechend der der Connect Unit zugeordneten Beziehungsrolle IssueToTopic, wird für jedes ausgewählte Themengebiet ein neues Beziehungsobjekt zwischen dem zugewiesenen Objekt der Entität Issue und einem Objekt der Entität Topic erstellt. Ausgangsparameter der Connect Unit sind die OID der zugewiesenen Ausgabe, sowie die OIDs der Themengebiete, für die ein Beziehungsobjekt erstellt wurde. Die Multichoice Index Unit as yet choosen topics listet alle Themengebiete auf, die der dargestellten Ausgabe bereits zugeordnet sind. Dies erfolgt über den Selektor [IssueToTopic] dieser Multichoice Index Unit, der die OID der in der Data Unit dargestellten Ausgabe über einen transportierenden Link erhält. Der OK-link, sowie der KO-link der Connect Unit führen zur Data Unit selected issue und transportieren dabei die OID der bearbeiteten Ausgabe. Nach Aktivierung und erfolgreicher Ausführung der Connect Operation werden nun die hinzugefügten Themengebiete angezeigt.

Figure 38. Erweiterte grafische Darstellung zur Anwendung einer Connect Unit.

Erweiterte grafische Darstellung zur Anwendung einer Connect Unit.

Disconnect Unit

Eine Disconnect Unit wird verwendet, um ein oder mehrere Beziehungsobjekte einer Beziehungsrolle zwischen zwei Entitäten zu entfernen, das heisst sie löscht die Verbindung zwischen Objekten der Quell-Entität und Objekten der Ziel-Entität einer Beziehung. Eine Disconnect Unit besitzt die gleichen zu definierenden Eigenschaften wie eine Connect Unit. Das Prinzip einer Disconnect Unit soll wieder am bisherigen Beispiel erläutert werden. Es wird nun zusätzlich noch eine Disconnect Unit hinzugefügt mit folgenden Eigenschaften:

Disconnect Unit

Nutzerdefinierter Name: Disconnect IssueToTopic
Beziehungsrolle: IssueToTopic
Quell-Selektor: [Issue.OID=SelIssue]
Ziel-Selektor: [Topic.{OID}=DelTopic]

Abbildung 39 zeigt das erweiterte Beispiel mit der Disconnect Unit Disconnect IssueToTopic. In der Multichoice Index Unit as yet choosen topics werden die zur Ausgabe zugeordneten Themengebiete aufgelistet. Um ein oder mehrere Themengebiete aus der Auswahl zu entfernen, können diese hier ausgewählt werden. Mit der Ausführung des einfachen kontextabhängigen Link zwischen der Unit as yet choosen topics und der Disconnect Unit, kann die Disconnect Operation aktiviert werden. Der Link transportiert dabei die OIDs der ausgewählten Themengebiete über den mehrwertigen Linkparameter DelTopic und weist diese dem Ziel-Selektor [Topics.OID=DelTopic] zur Auswertung zu. Über einen transportierenden Link wird, nach Aktivierung der Disconnect Unit, die OID der aktuell angezeigten Ausgabe durch den Linkparameter SelIssue dem Quell-Selektor [Issue.OID=SelIssue] zur Auswertung zugewiesen. Die Disconnect Unit entfernt nach Aktivierung für jedes ausgewählte Themengebiet die Verbindung zwischen der aktuellen Ausgabe und dem jeweiligen Objekt der Entität Topic. Nach erfolgreicher Ausführung werden diese Themengebiete nicht mehr in der Multichoice Index Unit as yet choosen topics aufgelistet. Der OK-link und der KO-link der Disconnect Unit führen, wie auch die der Connect Unit, in die Data Unit selected issue. Aus Übersichtsgründen werden diese beiden Ausgangslinks nicht in der Abbildung dargestellt.

Figure 39. Erweiterte grafische Darstellung zur Anwendung einer Disconnect Unit.

Erweiterte grafische Darstellung zur Anwendung einer Disconnect Unit.

Die textuelle Notation der Connect Unit Connect IssueToTopic und der Disconnect Unit Disconnect IssueToTopic aus Abbildung 39 wird im Folgenden dargestellt.

ConnectUnit Connect IssueToTopic
(source IssueToTopic;
[Issue.OID = SelIssue];
[Topic.OID = SelTopic])

DisconnectUnit Disconnect IssueToTopic
(source IssueToTopic;
[Issue.OID = SelIssue];
[Topic.OID = DelTopic])

Login Unit

Zur Beschreibung und Umsetzung der Zugriffskontrolle auf die Anwendung, sowie der Identitätsprüfung eines Nutzers, stellt WebML eine weitere vordefinierte Operation Unit bereit. Die Login Unit ist durch zwei feste Parameter Username und Password definiert, mit deren Hilfe die Identität des Nutzers überprüft wird. Nach erfolgreicher Verifikation wird der Nutzer zur Home Page der seiner Nutzergruppe zugeordneten Hypertext View geleitet. Die Zuweisung der zu überprüfenden Parameter geschieht typischerweise mit Hilfe einer Entry Unit. Folgendes Beispiel in Abbildung 40 zeigt die Verwendung einer Login Unit.

Die Page Login enthält eine Entry Unit Login data , die mit der Login Unit Login verbunden ist. Die Entry Unit und die Login Unit sind durch folgende Eigenschaften definiert:

Entry Unit

Nutzerdefinierter Name: Login data
Eingabefelder: Username, Password

Feldname1: Username
Datentyp: string
Initialwert: keine Angabe
Gültigkeitsbedingung: notnull

Feldname2: Password
Datentyp: password
Initialwert: keine Angabe
Gültigkeitsbedingung: notnull


Login Unit


Nutzerdefinierter Name: Login
definierte Verknüpfungen: username:=Uname, password:=Pword

Nach Eingabe von Username und Password und Betätigung des einfachen kontextabhängigen Links zwischen der Entry Unit Login data und der Login Unit Login, werden die Eingabewerte über die Linkparameter Uname und Pword übertragen. Durch definierte Verknüpfungen der Linkparameter mit den Attributen der Entität User in der Login Unit, werden die übertragenen Werte der Linkparameter Uname und Pword mit den Werten der Attribute username und password verglichen.

Figure 40. Grafische Darstellung zur Anwendung einer Login Unit.

Grafische Darstellung zur Anwendung einer Login Unit.

Die textuelle Notation der Login Unit Login aus Abbildung 40 wird im Folgenden dargestellt:

login Login
(parameters username:=Uname, password:=Pword)

Logout Unit

Eine Logout Unit dient der Beendigung der aktuellen Sitzung des eingeloggten Nutzers. Sie besitzt keine Eingangs- und Ausgangsparameter und kann durch einen kontextunabhängigen Link aktiviert werden. Nach erfolgreicher Logout Operation wird der Nutzer zur Home Page der Default Hypertext View geleitet, die allen Nutzern zugänglich ist und alle Funktionen bereitstellt, die keine Zugiffskontrolle benötigen. Abbildung 41 zeigt eine Page Logout die über einen kontextunabhängigen Link die Logout Operation einleitet.

Figure 41. Grafische Darstellung zur Anwendung einer Logout Unit.

Grafische Darstellung zur Anwendung einer Logout Unit.

Die textuelle Notation der Logout Unit Logout aus Abbildung 41 wird wie folgt definiert:

logout Logout

Transactions

Damit eine Sequenz von Operation Units als eine atomare Operation behandelt wird, werden sogenannte Transactions verwendet. Eine Transaction ist eine Art Box, die mehrere miteinander verknüpfte Operation Units enthält und dafür sorgt, dass diese als eine gemeinsame Einheit ausgeführt werden. Nur wenn jede einzelne Operation Unit erfolgreich ausgeführt wurde, gilt die gesamte Transaction als fehlerfrei ausgeführt. Sobald ein Fehler bei der Ausführung einer der Operation Units auftritt, werden alle vorhergehenden Operationen rückgängig gemacht und die Transaction wird als fehlerhaft angesehen. Damit ist die Ausführung voneinander abhängiger Operationen ohne Unterbrechung gesichert, so dass die Synchronisation mehrerer am gleichen System arbeitenden Nutzer gewährleistet ist und so kein fehlerhafter Datenbankzustand entstehen kann.

Das folgende Beispiel soll die Anwendung von Transactions verdeutlichen, indem der Registrierungsprozess eines neuen Autors erläutert wird. Zuvor wird kurz die Umsetzung der Personalisierung der Anwendung anhand des Personalisierungsmodells erläutert. Das Personalisierungsmodell umfasst einen Ausschnitt des Informationsmodells und ist in Abbildung 42 dargestellt.

Figure 42. Ausschnitt des Informationsmodells: Personalisierungsmodell des modellierten Journals.

Ausschnitt des Informationsmodells: Personalisierungsmodell des modellierten Journals.

Die Personalisierungsmodellierung wird durch die drei Entitäten User, Group und SiteView, sowie die Beziehungen User_DefaultGroup, User_Group und Group_SiteView umgesetzt. Die Nutzer des Systems sind Autoren, Gutachter, Redakteure und Administratoren, die jeweils eine Sub-Entität der Entität User sind. Für jede dieser Nutzergruppen wird ein Objekt der Entität Group angelegt. Jedem Nutzer ist damit über die Beziehung User_DefaultGroup genau eine Default Group zugeordnet. Ein Nutzer kann ausserdem noch weiteren Nutzergruppen angehören, als die ihm zugewiesene Default Group. Dies wird durch die Beziehung User_Group modelliert. Jeder Nutzergruppe des Systems ist genau eine Sicht auf den Hypertext zugeordnet, die nur die für diese Nutzergruppe zugänglichen Funktionen bereitstellt. Dieser Aspekt wird durch die Beziehung Group_SiteView modelliert.

Die Abhängigkeiten der Entitäten User, Group und SiteView voneinander, machen die Anwendung einer Transaction bei der Registierung eines neuen Autors notwendig. Die bisher erwähnten Nutzer sind registrierte Nutzer der Anwendung. Damit das Journal auch nicht registrierten Nutzern zugänglich ist, ist eine weitere öffentliche Hypertext View mit entsprechenden Funktionen vorhanden. Abbildung 43 zeigt einen Auschnitt des Hypertextmodells dieser Sicht, der den Registrierungsprozess eines neuen Autors darstellt.

Die Area Registration enthält die Page Registration mit einer Entry Unit Registration und einer Data Unit Group, sowie die Page Your Data mit der Data Unit Your Data. Die Registrierung eines neuen Autors erfordert weiterhin eine Create Unit, sowie zwei Connect Units. Im Folgenden sind die Eigenschaften der Content Units und Operation Units aufgelistet.

Data Units

Nutzerdefinierter Name: Group
Quell-Entität: Group
Selektor: [groupName="author"]
Zugeordnete Attribute: keine

Nutzerdefinierter Name: Your Data
Quell-Entität: Author
Selektor: default
Zugeordnete Attribute: usernamepasswordfirstNamelastNamebiographyemail

Entry Unit


Nutzerdefinierter Name: Registration
Eingabefelder: UsernamePasswordFirstnameLastnameBiography, Email

Feldname1: Username
Datentyp: string
Gültigkeitsbedingung: notnull

Feldname2: Password
Datentyp: password
Gültigkeitsbedingung: notnull

Feldname3: Firstname
Datentyp: string
Gültigkeitsbedingung: not null

Feldname4: Lastname
Datentyp: string
Gültigkeitsbedingung: not null

Feldname5: Biography
Datentyp: text

Feldname6: Email
Datentyp: string


Create Unit 

Nutzerdefinierter Name: Create Author
Quell-Entität: Author
Spezielle Verknüpfungen: username := Uname, password := Pword, firstName := First
lastName := Last, biography := Bio, email := Mail


Connect Units

Nutzerdefinierter Name: Connect UserdefGroup
Beziehungsrolle: UserToDefaultGroup
Quell-Selektor: [User.OID = NewUser]
Ziel-Selektor: [Group.OID = GroupID]

Nutzerdefinierter Name: Connect IssueToTopic
Beziehungsrolle: UserToGroup
Quell-Selektor: [User.OID = NewUser]
Ziel-Selektor: [Group.OID = GroupID]

Figure 43. Grafische Darstellung einer Transaction am Beispiel der Registrierung eines neuen Autors.

Grafische Darstellung einer Transaction am Beispiel der Registrierung eines neuen Autors.

Bei der Registrierung eines neuen Autors ist es notwendig, dass die einzelnen miteinander verketteten Operation Units als Einheit ausgeführt werden. Die Registrierung ist somit erst vollständig, wenn alle drei Operationen erfolgreich ausgeführt wurden. Damit diese Anforderung erfüllt ist, wird das Konzept der Transaction angewendet. Grafisch wird eine Transaction durch eine, die einzelnen Units umschließende, gestrichelte Box dargestellt. Nach der Ausführung des Links zwischen der Entry Unit Registration und der Create Unit Create Author wird die Create Operation aktiviert. Die Create Unit Create Author erzeugt ein neues Objekt der Entität Author. Die dafür notwendigen Attributwerte erhält sie durch die Eingabewerte der Entry Unit, die über Linkparameter an die Create Unit übergeben werden. Die Create Unit ist über ihren OK-link mit der Connect Unit Connect UserdefGroup verbunden.

Die Connect Operation ist der Beziehungsrolle UserToDefaultGroup zugeordnet, und weist dem neu erzeugten Autor seine entsprechende Nutzergruppe zu. Die Connect Unit erhält den Wert für den Quell-Selektor über den OK-link der Create Unit durch den Linkparameter NewUser. Der Ziel-Selektor benötigt die GroupOID der Nutzergruppe Author. Diese erhält er durch den Linkparameter GroupID des transportierenden Links der Data Unit Group, der die OID der Nutzergruppe mit groupName="author" überträgt.

Für jeden Nutzer wird ausserdem ein Objekt der Beziehungsrolle UserToGroup erzeugt. Der Quell-Selektor erhält die OID des neu angelegten Autors über den Linkparameter NewUser, sowie der Ziel-Selektor die OID der zugeordneten Nutzergruppe über den Linkparameter GroupID des OK-links der Connect Unit UserdefGroup. Der Ok-link der letzten Connect Unit führt zur Data Unit Your Data, um die Daten des neu erzeugten Autors anzuzeigen.

Mit dieser Verkettung der einzelnen Operation Units wird deutlich, dass nur nach erfolgreicher Ausführung aller Operationen eine fehlerfreie Funktion der Anwendung garantiert werden kann. Wird nur die Create Unit ausgeführt, nicht aber die folgende Connect Operation UserdefGroup, kann sich der Nutzer auch bei erfolgreicher Erzeugung des Author-Objektes nicht im System einloggen, da ihm keine Nutzergruppe zugewiesen wurde und folglich auch keine entsprechende Hypertext View.

Entwurf und Umsetzung eines wissenschaftlichen Online Journals

Einleitung

Im Beispielprojekt dieser Arbeit geht es um die Modellierung der wichtigsten Eigenschaften eines wissenschaftlichen Online Journals zur Publizierung von wissenschaftlichen Arbeiten im Web, unter Verwendung von WebML und WebRatio. In diesem Kapitel wird nun der Entwurf des Online Journals und die Umsetzung mit WebML und WebRatio vorgestellt. Zu Beginn wird in diesem Kapitel die Einbettung des Entwicklungsprozesses einer datenintensiven Webanwendung in das Entwicklungstool WebRatio näher erläutert.

Als Vorlage bei der Modellierung der wichtigsten Anforderungen, die im Informationsmodell umgesetzt wurden, dienten bereits vorhandene wissenschaftliche Online Journale im Web, sowie Überlegungen aus eigenen Erfahrungen und Vorstellungen. Als Beispiel wird die grundlegende Struktur des wissenschaftlichen Online Journals Forum Qualitative Sozialforschung FQS beschrieben. Anschließend wird der Entwurf des Online Journals anhand der Entwurfsphasen des Entwicklungsprozesses mit den entstandenen Entwurfsmodellen der WebML erklärt. Hierbei wird auch auf die Umsetzung mit WebRatio eingegangen.

Einbindung des Entwicklungsprozesses in WebRatio

WebRatio ist ein kommerzielles CASE (Computer Aided Software Engineering) Tool für die webbasierte Anwendungsentwicklung. Bei der Umsetzung des Online Journals wurde WebRatio 4.WS - Academic Edition verwendet. WebRatio wird gemeinsam mit dem Apache Webserver Tomcat auf dem System installiert, um die Anwendung lokal ausführen zu können. Die Anwendung von WebRatio basiert auf der Java Entwicklungsumgebung und benötigt mindestens JDK 1.3. um fehlerfrei zu arbeiten. Bei der Umsetzung dieses Projektes kam JDK 1.5 zum Einsatz.

Die Entwurfsmethoden von WebML, die den Entwurf der Daten, Funktionen und Präsentationseigenschaften voneinander separieren, werden durch WebRatio auf drei Entwurfsebenen abgebildet:

  • die Datenebene zur Unterstützung des Datenentwurfs

  • die Funktionsebene zur Unterstützung des Hypertextentwurfs und der Content Management Modellierung

  • die Präsentationsebene zur Festlegung von Layouteigenschaften

WebRatio unterstützt zudem die Implementierungsphase durch die automatische Erzeugung relationaler Datenbanken und Transformierung der Hypertext Views in Module entsprechender Entwicklungsplattformen wie JSP, Struts oder Microsoft.NET. ([CeriFrat03] S. 508 f.) Struts ist ein Open-Source-Framework für die Präsentationsschicht von Java-Webanwendungen. Die automatische Quellcodegenerierung ermöglicht so die schnelle Erstellung eines Prototypen der Webanwendung.

Die Oberfläche von WebRatio ist hinsichtlich der drei Entwurfsebenen in mehrere Bereiche gegliedert, um die getrennte Erstellung des Informationsmodells, des Hypertextmodells und die separate Zuweisung von Layouteigenschaften zu ermöglichen. WebRatio verfügt diesbezüglich über eine Editing View, eine Mapping View und eine Presentation View.

In der Editing View werden die Phasen Datenentwurf und Hypertextentwurf zusammengefasst. Es wird die Erstellung eines Entity Relationship Datenschemas unterstützt, indem der Entwickler mit grafischen Elementen die Entitäten, Attribute, Beziehungen und deren Eigenschaften beschreiben kann. Unabhängig vom Informationsmodell wird der Entwurf verschiedener Hypertext Views unterstützt. Auch hier sind grafische Elemente der WebML vorhanden, um die Eigenschaften des Hypertextes durch Areas, Pages, Units und Links zu beschreiben.

In der Mapping View werden die Datenquellen deklariert, auf die das modellierte Datenschema abgebildet werden soll. Anhand des Datenschemas wird automatisch eine relationale Datenbank erzeugt.

In der Presentation View können die Layouteigenschaften der Webanwendung festgelegt werden. Dazu gehören die Zuweisung vordefinierter XSL Stylesheets zu entsprechenden Hypertext Views oder einzelnen Pages und Units, oder die Möglichkeit, eigene XSL Stylesheets zu definieren. Weiterhin können in der Presentation View die einzelnen Content Units der Pages durch eine spezielle Ansicht in dieser Page positioniert werden.

Die grafische Oberfläche von WebRatio ist für jede dieser Views in vier Abschnitte unterteilt. Im linken Fensterbereich befindet sich der Projekt-Baum, zur Auflistung aller Elemente des aktuellen Projektes. Unterhalb des Projekt-Baums befindet sich ein Eigenschaftenfenster, um die Eigensschaften eines ausgewählten Elementes anzuzeigen und zu bearbeiten. Im rechten Fensterbereich befindet sich die Arbeitsebene, in der die Modelle durch grafische Elemente erstellt werden können. Unterhalb der Arbeitsebene befindet sich ein Mitteilungsfenster zur Anzeige eventueller Modellierungsfehler und Warnungen. In Abbildung 44 ist die Gliederung der Programmoberfläche dargestellt.

Figure 44. Gliederung der grafischen Oberfläche von WebRatio.

Gliederung der grafischen Oberfläche von WebRatio.

Merkmale wissenschaftlicher Journale am Beispiel FQS

Folgende Beschreibungen erläutern den groben Aufbau und die Struktur des wissenschaftlichen Online Journals FQS [FQS]. Das Forum Qualitative Sozialforschung ist eine mehrsprachige wissenschaftliche Online-Zeitschrift für qualitative Sozialforschung, bestehend seit 1999. Es erscheinen alle 4 Monate so genannte Schwerpunktausgaben, die für die qualitative Forschung wesentliche Themengebiete behandeln. Außerdem erscheinen ausgewählte Einzelbeiträge und Beiträge in den Rubriken Reviews, Debatten, Tagungen und Interviews. Bei FQS handelt es sich um ein offenes Projekt mit Beteiligten wie Leser, Autoren, Mitgliedern des wissenschaftlichen Beirates, sowie der Online-Redaktion. Die Redaktionsmitglieder sind nach den entsprechenden Rubriken unterteilt.

In FQS gibt es folgende Rubriken:

  • Themenbände

    Alle 4 Monate erscheinen so genannte Schwerpunktbände. Diese werden je nach thematischem Schwerpunkt von verschiedenen Personen editiert. Jeder Schwerpunktband enthält neben Beiträgen, die unmittelbar das jeweilige Schwerpunktthema betreffen, auch ausgewählte Einzelbeiträge aus verschiedenen Bereichen qualitativer Forschung. Unter der Rubrik Themenbände werden die bisher veröffentlichten Themenbände mit Angabe der laufenden Nummer sowie des Titels aufgelistet. Nach Auswahl eines Themenbandes (neue Seite) werden alle Beiträge sortiert nach zugehörigem Thema nacheinander aufgelistet mit Angabe der Autoren und Beitragtitel und Link zum Volltext und Abstract des Beitrags. Informationen zu den einzelnen Autoren sind über einen Link auf der jeweiligen Seite des ausgewählten Beitrags aufrufbar.

  • Debatten

    Debatten sollen paralell zu den zu festen Zeiten veröffentlichten Schwerpunktbänden eine kontroverse Diskussion von Fragen ermöglichen. Die bisher eröffneten Debatten werden mit Angabe des Titels als Link aufgelistet. Nach Auswahl einer Debatte werden allgemeine Informationen zu dem Debattenthema angezeigt, sowie alle zu dieser Debatte bisher veröffentlichten Beiträge.

  • Reviews

    Die Rubrik Reviews soll der Besprechung von Medieneinheiten, d.h. von Büchern, Buchreihen, Filmen, CD-Roms etc. dienen. In der Rubrik erhält man die Möglichkeit sich über verfügbare Medieneinheiten zu informieren, zu denen potentiell Rezensionen angefertigt werden können, eine Vorschau auf Rezensionen, die in Zukunft erscheinen werden, sowie eine Liste bereits veröffentlichte Rezensionen. Nach Auswahl des Links für veröffentlichte Besprechungen werden alle Rezensionen aufgelistet mit Angabe der rezensierten Medieneinheit, sowie des Autors dieser Rezension, mit Link zum Volltext oder Abstrakt des Beitrags.

  • Interviews

    In der Rubrik Interviews werden Gespräche mit Vertreterinnen und Vertretern der qualitativen Sozialforschung veröffentlicht. Über einen Link gelangt man zu einer Auflistung der Interviews mit Angabe des Interviewten sowie des Interviewleiters, mit Link zu Volltext sowie Abstrak des Beitragst.

  • Tagungen

    Mit der Rubrik Tagungen ist beabsichtigt, mit Berichten über Tagungen, Konferenzen, Symposien oder Workshops zu informieren. Es sollen nicht nur Rahmendaten zu Tagungen zur Verfügung gestellt werden, sondern auch inhaltliche Diskussionsbeiträge.

Für die einzelnen Rubriken gibt es speziell verantwortliche Redakteure, die auf der Webseite ausgewiesen sind. In FQS erfolgt die Einreichung von Beiträgen über die Zusendung von E-Mails an den verantwortlichen Redakteur. Andere wissenschaftliche Online Journale ermöglichen das Einreichen von Beiträgen über die Webseite, sofern der Benutzer registriert ist. Die eingereichten Beiträge durchlaufen üblicherweise einen oder mehrere Gutachtenprozesse, die durch wissenschaftliche Mitarbeiter des Journals oder extern mitarbeitende Wissenschaftler durchgeführt werden.

Die Strukturen von FQS und weiteren wissenschaftlichen Online Journalen im Web dienten als Orientierung, um die typischen Merkmale wissenschaftlicher Online Journale am Beispielprojekt umzusetzen.

Es gibt typischerweise mehrere Nutzergruppen wie Redakteure, Autoren, und Gutachter. Desweiteren werden Beiträge und Journalausgaben verwaltet. Diese werden dem Nutzer auf verschiedene Weise zugänglich gemacht. Die Umsetzung des Ablaufs bei der Einreichung von Beiträgen, sowie die Verwaltung der Gutachtenprozesse, erfolgte nach eigenen Vorstellungen, da diese Verfahren in jedem Online Journal individuell gehandhabt werden.

Allgemeine Anforderungsbeschreibung des Online Journals

Wissenschaftliche Online Journale bieten eine Vielzahl von Daten im Internet an. Diese müssen für die Veröffentlichung geeignet strukturiert und aufbereitet werden. Die Komplexität einer Webanwendung steigt mit der Anzahl der zu verwaltenden Daten und dem angebotenen Funktionsumfang. Mit einer allgemeinen Formulierung der Anforderungen an eine solche Anwendung wird ein grundlegendes Bild des Systems herausgearbeitet, das die wichtigsten Systemnutzer und die grundlegenden Funktionen der Anwendung festhält.

Der erste Schritt der Anforderungssammlung ist die Bestimmung der einzelnen Benutzer der Anwendung. Diese werden in Gruppen mit unterschiedlichen Zielen und Verhalten unterteilt. Jeder Nutzergruppe wird typischerweise eine Sicht auf vorhandene Daten und verschiedene Funktionen zugeordnet, um die Bedürfnisse dieser Nutzergruppe zu erfüllen. Als ein erstes Kriterium bei der Gruppierung der Nutzer wird die Einteilung in externe und interne Nutzer vorgenommen. Externe Nutzer sind die Leser des Journals, die nicht im System registriert sind und keinen Einfluss auf die Daten der Anwendung nehmen können. Interne Nutzer sind im System registriert und haben spezielle Zugriffsrechte, um die Daten der Anwendung entsprechend zu verändern.

Definition der Nutzergruppen

Abbildung 45 stellt die Hierarchie der möglichen Nutzer eines Online Journals dar. Die Gruppe der nicht registrierten Nutzer besteht aus den Lesern des Journals mit eingeschränktem Zugriff auf die Daten der Anwendung. Die registierten Nutzer der Anwendung können entsprechend ihrer Zugriffsrechte die Daten der Anwendung verändern. Zu den registrierten Nutzern des Online Journals gehören Autoren, Redakteure, Gutachter und Administratoren. Zur Verdeutlichung der Abgrenzung der Nutzergruppen folgt eine allgemeine Beschreibung der Zugriffsmöglichkeiten der Nutzer auf die Daten der Anwendung.

Leser

Ein Leser besitzt keinen Account und ist somit nicht im System registriert. Er hat nur eingeschränkten Zugriff auf die von der Anwendung angebotenen Inhalte und Funktionen. Er erhält allgemeine Informationen über die Wissenschaftsdisziplin dieses Journals, sowie über das Journal selbst. Er kann die Beiträge der einzelnen Rubriken (Essays, Artikel), sowie Ausgaben des Journals lesen und erhält Informationen zu den jeweiligen Autoren. Zugriff auf weitere Dienste und Daten, wie das Bereitstellen eigener Beiträge, die Diskussion über einzelne Beiträge, ausführliche Informationen über Gutachter oder Redakteure ist ihm nicht möglich.

Autor

Autoren sind im System mit den wichtigsten persönlichen Angaben registriert. Ein Autor hat zusätzlich zu den Funktionen des Lesers die Möglichkeit, einen eigenen Beitrag zu veröffentlichen. Dies erfolgt über ein speziell dafür vorgesehenes Formular. Ein Autor kann seine Beiträge in einem speziell dafür vorgesehenem Bereich verwalten, und eventuelle Gutachten seiner Beiträge lesen. Ein Autor kann Kommentare (in einem möglichen Diskussionsforum) zu einzelnen Beiträgen abgeben, erhält ausführliche Informationen über einzelne Autoren und kann Kontakt mit den verantwortlichen Redakteuren aufnehmen.

Redakteur

Redakteure sind bestimmten Rubriken des Journals zugeordnet, für die sie verantwortlich sind. Sie sind für das Beitragsmanagement (bearbeiten, löschen, veröffentlichen) verantwortlich. Sie bereiten Gutachten für die eingstellten Beiträge vor und ordnen diese ausgewählten Gutachtern zu. Sie entscheiden als die ersten Personen, über die mögliche Publizierung eines Beitrags. Ausserdem können sie Themengebiete und Schlüsselwörter anlegen, bearbeiten oder löschen.

Gutachter

Ein Gutachter hat Zugriff auf die ihm zugewiesenen Beiträge und kann diese lesen und kommentieren, indem er in einem dafür vorgesehenen Formular das Gutachten formuliert. Er erhält ausserdem ausführliche Informationen zu Autoren, Redakteuren und weiteren registrierten Gutachtern. Ebenso kann er Kontakt mit dem für das Gutachten verantwortlichen Redakteur aufnehmen

Administrator

Der Administrator verwaltet (anlegen, bearbeiten, löschen) die Useraccounts. Er kann neue Rubriken im Journal anlegen, bearbeiten oder löschen. Ausserdem hat ein Administrator Zugriff auf alle veröffentlichten Beiträge und kann diese entsprechend verwalten.

Figure 45. Generalisierungshierarchie der Nutzergruppen des Online Journals.

Generalisierungshierarchie der Nutzergruppen des Online Journals.

Kernobjekte der Anwendung

Zur Anforderungsbeschreibung gehört die Identifikation der Kernobjekte der Anwendung. Sie stellen die wichtigsten Datenobjekte dar, die zur Erfüllung des Anwendungsziels beitragen. Sie können durch bestimmte Nutzergruppen verwaltet werden. Die identifizierten Kernobjekte mit ihren Eigenschaften sind:

  • Journal (journal)

    URL          
    Beschreibung              
    Journalname     

  • Journalausgabe ( issue )

    Durch das Online Journal werden fortlaufende Journalausgaben herausgegeben.

    Ausgabennummer            
    Ausgabentitel    
    Beschreibung    

  • Beitrag (contribution)

    Jede Journalausgabe besteht aus mehreren zugeordneten Beiträgen, die durch Autoren bereitgestellt werden.

    Titel          
    Datei               
    Abstract    
    Erstellungsdatum
    Datum der Veröffentlichung
    zugeordnetes Themengebiet

  • Autor (author)

    Vorname           
    Nachname           
    Telefonnummer    
    Handynummer
    Biografiedaten

  • Gutachten (review)

    Gutachtenname          
    Datei            
    Beschreibung    
    Datum der Gutachtenfertigstellung  

  • Gutachter (reviewer)

    Vorname           
    Nachname           
    Telefonnummer  
    Handynummer

  • Rubrik (rubric)

    Rubrikname         
    Beschreibung

Hypertext Views und funktionale Anforderungen

Entsprechend der identifizierten Nutzergruppen werden fünf Hypertext Views definiert.

1. Journal Web – Hypertext View für die Nutzergruppe Leser (öffentlich)

Ermöglicht dem Nutzer den Zugriff auf publizierte einzelne Beiträge und Ausgaben des Journals, Informationen über registrierte Autoren, Informationen über Redakteure des Journals ( Namen, Email, Telefon) und allgemeine Informationen über das Journal.

Page Home: allgemeine Informationen zum Journal

Page Login

Area Contributions:

Eine Rubrikseite listet alle Rubriken auf. Die Seite zu jeder Rubrik listet alle Beiträge der zuvor ausgewählten Rubrik, sowie die Themengebiete des Journals auf. Die Beitragsauswahl kann so auf bestimmte Themengebiete eingeschränkt werden. Die Beitragsseite zeigt Detailinformationen des ausgewählten Beitrags (zugehörige Rubrik, Titel, Autor(en), Schlüsselwörter, Abstract, Themengebiet und optional Kurzinformationen zur zugehörigen Journalausgabe). Die Schlüsselwortseite listet alle Schlüsselworte auf. Nach Auswahl der gewünschten Schlüsselworte werden in der Ergebnisseite alle Beiträge aufgelistet, die eines der gewählten Schlüsselwörter enthalten. Die Autorenseite listet alle Autoren des Journals auf. Nach Auswahl eines Autors bekommt man Kurzinformationen (mit Link zu Autorendetails), sowie eine Liste aller Beiträge, in denen der Autor mitgewirkt hat, angezeigt. Auf der Suchseite ist es möglich nach einem Autor, nach Beiträgen durch Angabe des Titels(Titelwörter) und/oder des Erstellungsdatums des Beitrags oder nach bestimmten Schlüsselwörtern zu suchen.

Area Issues:

Die Ausgabenseite zeigt eine Liste aller Ausgaben des Journals mit Angabe des Titels, Ausgabendetails, sowie eine Liste der Beiträge einer ausgewählten Ausgabe. Die Suchseite ermöglicht die Suche nach Titelnamen sowie Ausgabenummern

Area Topics:

Die Themenbereichsseite listet alle Themenbereiche des Journals auf, mit der Beschreibung des Themengebiets und einer Auflistung aller zugeordneten Beiträge (Jeder Beitrag ist genau einem Themengebiet zugeordnet).

Area Authors:

Die Autorenseite listet alle Autoren des Journals auf und zeigt Details zum ausgewählten Autor, mit Link zu Beitragsseite des Autors. Die Suchseite ermöglicht die Suche nach Autoren.

Area Registration:

Eine Informationsseite enthält Informationen zum Registrierungsprozess und weitere Informationen darüber, welche zusätzlichen Funktionen nach der Registrierung zur Verfügung stehen. Die Registrierungsseite enthält ein Formular mit den benötigten Eingabefeldern.

Area Journal Information:

Die Area enthält eine Informationsseite mit allgemeinen Informationen zum Journal. Eine Redakteurseite enthält die Liste der Redakteure.

funktionale Anforderungen

  • Beiträge ansehen

    gegliedert nach Rubriken und nach Themengebieten sortiert
    gegliedert nach Schlüsselwörtern
    gegliedert nach Autoren
    gegliedert nach Themengebiet

  • Beiträge suchen

    von bestimmtem Autor
    mit bestimmtem Titel und Erstellungsdatum
    mit bestimmten Schlüsselwörtern

  • Beitragdetails lesen

  • Vorveröffentlichte Beiträge anzeigen (nur Abstract lesbar)

  • Journalausgaben ansehen

  • Journalausgaben suchen

  • zukünftige Journalausgaben ansehen

  • Autoren auflisten

  • Autor suchen

  • Im System registrieren

  • Journalinformationen lesen

  • Redakteure auflisten

2. Authors - Hypertext View für die Nutzergruppe Autor (geschützt)

Zusätzlich zu den Funktionen eines normalen Lesers besitzt ein Autor einen Bereich zur Beitragsverwaltung, mit der Möglichkeit, Beiträge einzureichen, zu bearbeiten, oder entsprechend eines Gutachtens zu korrigieren. Weiterhin gibt es einen Bereich zur Verwaltung der Accountdaten.

Page Author Home

Page Logout

Page Change Group: Wenn der Nutzer mehreren Nutzergruppen zugeordnet ist, kann er über diese Funktion die Gruppe wechseln.

Area Contribution Management:

Der Autor kann neue Beiträge einreichen, indem er ein dafür vorgesehenes Formular ausfüllt, mit Angabe des Titels, Erstellungsdatum einem Kommentar, sowie dem Upload der entsprechenden Datei. Im nächsten Schritt muss der Autor eine Rubrik und ein Themengebiet auswählen. Er kann ausserdem Schlüsselwörter und mitarbeitende Autoren eintragen. Diese müssen bereits im System registriert sein, damit sie dem Beitrag zugewiesen werden können. Der Autor kann Beiräge zu einer bestimmten Journalausgabe einreichen, sowie unabhängig von einer gewünschten Journalausgabe. Beiträge werden grundsätzlich nur mit einer Journalausgabe veröffentlicht, ansonsten erscheinen sie als vorveröffentlichte Beiträge. Eingereichte Beiträge erscheinen in der Auflistung der neu eingereichten Beiträge und können hier nochmals nachträglich bearbeitet werden. In einem Bereich Gutachtenverwaltung werden die Beiträge je nach Bearbeitungstand aufgelistet (Beiträge im ersten Gutachtenprozess, Beiträge im 2. Gutachtenprozess, Beiträge zur Korrektur). Ein zur Korrektur freigegebener Beitrag kann vom Autor korrigiert werden und für das Zweitgutachten eingereicht werden. Der Autor kann hier die Gutachten der einzelnen Beiträge lesen. Die eigenen durch den Redakteur veröffentlichten oder gelöschten Beiträge können auf einer weiteren Seite aufgelistet werden.

Area My Account:

Der Autor kann seine persönlichen Daten und seine Accountdaten ansehen. Über ein entsprechendes Formular können die Accountdaten (Nutzername, Passwort) und die persönlichen Daten geändert werden.

funktionale Anforderungen:

  • Login / Logout

  • Beitrag einreichen

  • Beitrag für bestimmte Journalausgabe einreichen

  • Beitrag bearbeiten

  • Beitrag löschen (solange noch nicht im 1. bzw. 2. Gutachtenprozess)

  • Gutachten lesen

  • Beitrag korrigieren

  • selbst eingereichte Beiträge ansehen

  • veröffentlichte/gelöschte Beiträge ansehen

  • Accountdaten und persönliche Daten ansehen / ändern

3. Editor - Hypertext View für die Nutzergruppe Redakteur (geschützt)

Ein Redakteur besitzt einen Bereich zur Beitragsverwaltung, mit der Möglichkeit neu eingereichte Beiträge zu bearbeiten, sowie Gutachten zu Beiträgen vorzubereiten (Erstgutachten bzw. Zweitgutachten) und ausgewählten Gutachtern zuzuweisen. Weiterhin kann ein Redakteur neue Themenbereiche anlegen, bearbeiten oder löschen. Ein Redakteur kann ausserdem eine neue Ausgabe des Journals anlegen, für die er verantwortlich ist und die Beiträge auswählen, die in diese Ausgabe aufgenommen werden. Er kann sich Informationen über Autoren, andere Redakteure und Gutachter entsprechend den ihnen zugeordneten Themengebieten auflisten lassen. Weiterhin gibt es einen Bereich zur Verwaltung der Accountdaten.

Page Editor Home

Page Logout

Page Change Group: Wenn der Nutzer mehreren Nutzergruppen zugeordnet ist, kann er über diese Funktion die Gruppe wechseln.

Area Contribution Management:

Dem Redakteur werden alle eingereichten Beiträge aufgelistet. Dabei wird zwischen neu eingereichten und bereits korrigierten Beiträgen unterschieden. Der Redakteur kann neu eingereichte Beiträge bearbeiten (Themengebiet ändern, Rubrik ändern, Schlüsselwörter hinzufügen / entfernen). Er kann für neu eingereichte Beiträge die Erstgutachten vorbereiten, indem er Titel, Kommentar und einen Gutachter zuweist. Das gleiche Verfahren wird bei korrigierten Beiträgen vollzogen. Der Redakteur bereitet dann entsprechende Zweitgutachten vor. Im Bereich Review Management werden die in Bearbeitung befindlichen Beiträge aufgelistet (im ersten Gutachten, im zweiten Gutachten, in Korrektur). Die Gutachten der einzelnen Beiträge können aufgelistet werden. Der Redakteur sieht dabei die Empfehlungen der jeweiligen Gutachter, und entscheidet dann ob ein Beitrag gelöscht, veröffentlicht oder korrigiert werden soll. Ein Redakteur kann alle veröffentlichten und gelöschten Beiträge ansehen, sowie den zugehörigen Gutachten. Beiträge die zu einer dem Redakteur zugeordneten Journalausgabe eingereicht wurden, werden separat aufgelistet. Bei der entgültigen Entscheidung über die Veröffentlichung eines Beitrags, kann der Redakteur auswählen, ob der Beitrag mit dieser Journalausgabe veröffentlicht werden soll oder als vorveröffentlichter Beitrag abgespeichert wird.

Area Topic Management:

Der Redakteur kann sich alle Themengebiete auflisten lassen, diese bearbeiten, löschen oder ein neues Themengebiet anlegen. Weiterhin kann er neue Schlüsselwörter anlegen und bearbeiten.

Area Issue Management:

Es werden alle Ausgaben des Journals mit den zugehörigen Beiträgen aufgelistet. Ein Redakteur hat die Möglichkeit eine neue Ausgabe anzulegen bzw. zu bearbeiten. Er ist dann für die Beiträge der Ausgabe verantwortlich, das heisst alle Beiträge die von Autoren für eine bestimmte Ausgabe eingereicht werden, werden diesem Redakteur angezeigt. Bevor eine Ausgabe aktiviert wird, ordnet der Redakteur die gewünschten Beiträge zu. Nach Fertigstellung einer Journalausgabe kann der Redakteur diese aktivieren. Die derzeit aktuelle Journalausgabe wird dann mit dieser Ausgabe ausgetauscht.

Area My Account:

Der Redakteur kann seine persönlichen Daten und seine Accountdaten ansehen. Über ein entsprechendes Formular können die Accountdaten (Nutzername, Passwort) und die persönlichen Daten geändert werden.

Area Journal People:

Die Redakteurseite enthält eine Liste aller Redakteure mit Detailinformationen. Die Autorenseite enthält eine Liste aller Autoren, mit entsprechenden Detailinformationen. Die Gutachterseite enthält eine Liste aller Gutachter.

funktionale Anforderungen:

  • Login / Logout

  • Liste neu eingestellter / korrigierter Beiträge ansehen

  • Beitrag bearbeiten

  • Gutachten vorbereiten (1. Gutachten bzw. 2. Gutachten)

  • Gutachten bearbeiten

  • vorbereitete Gutachten löschen

  • Gutachten „freischalten“

  • Gutachten ansehen

  • Beitrag bewerten (veröffentlichen, nicht veröffentlichen oder in Korrektur schicken)

  • veröffentlichte / gelöschte Beiträge ansehen

  • Themengebiete auflisten

  • Themengebiet bearbeiten

  • Themengebiet löschen

  • Neues Themengebiet anlegen

  • Neue Ausgabe anlegen / bearbeiten / löschen

    Themengebiete der Ausgabe festlegen
    Beiträge zuordnen / entfernen

  • Ausgabe freischalten

  • Ausgaben auflisten

  • Accountdaten und persönliche Daten ansehen / ändern

  • Autoren auflisten / Detailinformationen ansehen

  • Redakteure auflisten / Detailinformationen ansehen

  • Gutachter auflisten / Detailinformationen ansehen

4. Reviewer - Hypertext View für die Nutzergrupppe Gutachter (geschützt)

Ein Gutachter besitzt einen Bereich zur Gutachtenverwaltung, mit der Auflistung der ihm zur Begutachtung zugewiesenen Beiträge, getrennt nach Erstgutachten und Zweitgutachten. Er hat die Möglichkeit die vorbereiteten Gutachten zu bearbeiten und kann anschließend eine Empfehlung abgeben (zur Korrektur, zur Veröffentlichung, zum Löschen) Weiterhin besitzt ein Gutachter einen Bereich Review History, in dem er die von ihm begutachteten Beitrage bzw. seine Gutachten ansehen kann. Weiterhin gibt es einen Bereich zur Verwaltung der Accountdaten.

Page Reviewer Home

Page Logout

Page Change Group: Wenn der Nutzer mehreren Nutzergruppen zugeordnet ist, kann er über diese Funktion die Gruppe wechseln.

Area Review Management:

Auflistung der Beiträge, die vom Gutachter bewertet werden sollen. Die Auflistung erfolgt nach Einteilung in „zu bearbeitende Erstgutachten“ und “zu bearbeitende Zweitgutachten“. Der Gutachter kann das zugewiesene Gutachten bearbeiten und dann eine Empfehlung abgeben ( für Korrektur , für Veröffentlichung, zum Löschen )

Area Review History:

Der Gutachter kann hier die von ihm bearbeiteten Gutachten bzw. Beiträge ansehen. Die Auflistung erfolgt getrennt in Beitragslisten oder Gutachtenlisten.

Area My Account:

Der Gutachter kann seine persönlichen Daten und seine Accountdaten ansehen. Über ein entsprechendes Formular können die Accountdaten (Nutzername, Passwort) und die persönlichen Daten geändert werden.

Area Review Information:

Der Bereich enthält Informationen über die Durchführung eines Gutachtens.

funktionale Anforderungen:

  • Login / Logout

  • Zu bearbeitende Gutachten anzeigen

  • Erstgutachten bearbeiten

    Gutachten in Formular eingeben oder Datei hochladen
    Kommentar zum Gutachten formulieren
    Empfehlung abgeben

  • Zweitgutachten bearbeiten

    Gutachten in Formular eingeben oder Datei hochladen
    Kommentar zum Gutachten formulieren
    Empfehlung abgeben

  • Informationen über Gutachtenerstellung ansehen

  • Accountdaten und persönliche Daten ansehen / ändern

  • Veröffentlichte oder gelöschte Beiträge ansehen

  • Bearbeitete Gutachten ansehen

  • Beitrag bewerten (veröffentlichen, nicht veröffentlichen oder in Korrektur schicken)

  • Veröffentlichte / gelöschte Beiträge ansehen

5. Administrator - Hypertext View für die Nutzergruppe Administrator (geschützt)

Der Administrator verfügt über einen Bereich Nutzerverwaltung, zum Anlegen, Bearbeiten und Löschen von Nutzeraccounts und weiterhin einen Bereich Journal Administration zum Anlegen neuer Rubriken, bearbeiten oder löschen von Rubriken, sowie zum Bearbeiten allgemeiner Journalinformationen.

Page Administrator Home

Page Logout

Page Change Group: Wenn der Nutzer mehreren Nutzergruppen zugeordnet ist, kann er über diese Funktion die Gruppe wechseln.

Area Contribution Management:

Im Bereich der Beitragsverwaltung kann der Administrator alle veröffentlichten und gelöschten Beiträge auflisten, sowie Beitragsänderungen an bereits veröffentlichten Beiträgen vornehmen.

Area Journal Administration:

Im Bereich der Journalverwaltung können die allgemeinen Daten des Journals verändert werden. Im Bereich der Rubrikverwaltung kann der Administrator neue Rubriken anlegen, bearbeiten und löschen.

Area User Administration:

Der Bereich Nutzerverwaltung ermöglicht das Anlegen, Bearbeiten und Löschen der Nutzeraccounts. Der Bereich ist gegliedert in eine Autorenverwaltung, Redakteurverwaltung und Gutachterverwaltung.

Area My Account:

Der Administrator kann seine persönlichen Daten und seine Accountdaten ansehen. Über ein entsprechendes Formular können die Accountdaten ( Nutzername, Passwort) und die persönlichen Daten geändert werden.

funktionale Anforderungen:

  • Login / Logout

  • Auflistung aller veröffentlichten und gelöschten Beiträge

  • Beitragdetails von bereits veröffentlichten Beiträgen ändern

  • Neuen Autoraccount anlegen / bearbeiten / löschen

  • Neuen Redakteuraccount anlegen / bearbeiten / löschen

  • Neuen Gutachteraccount anlegen / bearbeiten / löschen

  • Autoren/Redakteure/Gutachter suchen

  • Autoren/ Redakteure/ Gutachter auflisten

  • Nutzerdetails anzeigen

  • Journalinformationen bearbeiten

  • Rubriken anlegen / bearbeiten / löschen

  • Accountdaten und persönliche Daten ansehen / ändern

Fazit

Die Phase der Anforderungsanalyse besitzt eine enorme Wichtigkeit für den Entwurf und die Umsetzung einer datenintensiven Webanwendung. Je komplexer die Anforderungen sind, desto wichtiger ist es, ein abstraktes Bild der zu entwickelnden Webanwendung mittels einfacher Beschreibungen zu formulieren. Die in Kapitel 3.3.1 vorgeschlagene Vorgehensweise zur Erstellung einer Anforderungsbeschreibung ist keine einzuhaltene Vorschrift. Die Beschreibung der funktionalen Anforderungen sollte in Form von ausführlichen Anwendungsfallbeschreibungen erfolgen. Den weiteren Mitarbeitern des Projektes, die in verschiedenen Phasen des Entwicklungsprozesses zum Einsatz kommen, kann nur so eine präzise Vorstellung von der geplanten Webanwendung vermittelt werden. Beim Entwurf dieses Online Journals sind keine weiteren Personen am Entwicklungsprozess beteiligt. Aus diesem Grund wurde auf ausführliche Anwendungsfallbeschreibungen verzichtet. Die Anforderungsbeschreibung enthält die Defintion der wichtigsten Eigenschaften der identifizierten Nutzergruppen, eine Auflistung der Kernobjekte, allgemeine Beschreibungen der möglichen Hypertext Views und eine Aufzählung der wichtigsten zu erfüllenden Funktionen der Anwendung, strukturiert nach Nutzergruppen. Für den weiteren Entwurf des Online Journals sind diese Beschreibungen ausreichend.

Umsetzung des Datenentwurfs

Das Ziel der Datenentwurfsphase ist die Modellierung des Online Journals durch ein Informationsmodell. Es werden die Struktur der identifizierten Datenobjekte und deren Beziehungen untereinander visualisiert. Der Entwurf des Informationsmodells erfolgt über mehrere Verfeinerungsstufen. Die in Kapitel 3.3.2 beschriebene Möglichkeit, schrittweise ein in sich konsistentes Modell zu erhalten, ist nicht unbedingt erforderlich. Die schrittweise Erweiterung des Informationsmodells mit entsprechenden Subschemata wurde bei der Umsetzung des Informationsmodells dieses Online Journals nicht explizit angewendet.

Ein erster Entwurf des Informationsmodells für das Online Journal erfolgte ohne die Verwendung von WebRatio. Abbildung 1 Anhang D zeigt die Datenstruktur, sowie die Beziehungen der einzelnen Objekte untereinander. Eine minimierte Variante dieses Informationsmodells wurde mit WebRatio umgesetzt und ist in Abbildung 46 dargestellt.

Der nächste Abschnitt soll kurz die Ansätze der Entwurfsmethodik von WebML zur Datenmodellierung aufgreifen und auf das umgesetzte Informationsmodell übertragen.

Anwendung der Entwurfsmethodik von WebML

Die in Kapitel 3.3.2 erwähnte Modellierungsmethodik für den Entwurf eines Informationsmodells nimmt die Eigenschaften datenintensiver Webanwendungen als Ansatz für die Modellierung der Datenstruktur. Ausgehend von einem Grundgerüst des Modells, gebildet durch die in der Anforderungbeschreibung identifizierten Kernobjekte, werden entsprechend der Anwendungsanforderungen schrittweise verschiedene Typen von Subschemata hinzugefügt.

Kernsubschemata

Die Definition von Kernsubschemata erfolgt intuitiv durch die Anwendung festgelegter Modellierungsregeln, wie die Extrahierung mehrwertiger Attribute eines Kernobjektes in eine eigenständige Entität, die über eine Beziehung mit dem Kernobjekt verbunden ist. Ein Beispiel hierfür ist die Zuordnung mehrerer Schlüsselwörter zu einem Beitrag. Die Entitäten Contribution und Keyword sind über eine mehrwertige Beziehung miteinander verbunden. Durch diese schrittweise Erweiterung eines Kernobjektes mit zugehörigen Komponenten oder extrahierten mehrwertigen Attributen wird das Kernsubschema gebildet.

Zugriffssubschemata

Eine typische Eigenschaft datenintensiver Webanwendungen ist die hierarchische Gliederung von Daten, um den gezielten Zugriff auf ein oder mehrere Datenobjekte zu ermöglichen. Mehrstufige Zugriffshierarchien sind besonders von Online-Kaufhäusern bekannt. Hier werden verschiedenste Warengruppen angeboten, die wiederum in mehrere Kategorien und Unterkategorien strukturiert sein können und dadurch den Nutzer direkt zu einer bestimmten Produktmenge verweisen. Die Verwendung mehrstufiger Zugriffshierarchien ist in einem Online Journal weniger von Bedeutung. Der Zugriff auf die Kernobjekte erfolgt meist über einstufige Strukturierung. Der Zugriff auf Beiträge des modellierten Online Journals wird über die Zuordnung zu Rubriken, Themengebieten oder Schlüsselwörtern vorgenommen. Im Informationsmodell aus Abbildung 1 Anhang D ist eine mehrstufige Hierarchie innerhalb der Themengebiete modelliert. Es gibt eine bestimmte Anzahl an Hauptthemengebieten, die wiederum weitere Unterthemengebiete beinhalten können. Diese Verschachtelung kann beliebig fortgesetzt werden. Dies ist ein Beispiel für ein identifiziertes Zugriffssubschema.

Verbindungssubschemata

Ein Verbindungsschema drückt die semantische Beziehung zwischen Kernobjekten aus. Über diesen Ansatz können Navigationseigenschaften einer Anwendung und ihrer Datenobjekte beschrieben werden. Ein Beispiel eines Verbindungssubschemas ist die Verbindung zwischen der Entittät Issue und der Entität Contribution. Das Online Journal ermöglicht unabhängig voneinander, einerseits den Zugriff auf die einzelnen Journalausgaben, und andererseits den Zugriff auf die einzelnen veröffentlichen Beiträge. Beiträge sind meist einer bestimmten Journalausgabe zugeordnet. Über eine entsprechende Navigationsbeziehung kann über die Journalausgaben auf die zugeordneten Beiträge zugegriffen werden. Ebenso kann über einen Beitrag auf die zugehörige Journalausgabe verwiesen werden. Ein weiteres Beispiel ist die Verbindung zwischen Autoren und Beiträgen. Autoren werden ebenfalls als Kernobjekte der Anwendung angesehen, da der Nutzer, unabhängig von ihrer Zuordnung zu Beiträgen, Informationen zu Autoren bekommen kann. Die Verbindungsbeziehung zwischen den Entitäten Author und Contribution ermöglicht sozusagen die Navigation von Beitragsinformationen zu entsprechenden Autoreninformationen und umgekehrt.

Personalisierungssubschema

Das Personalisierungssubschema erweitert die eigentliche Datenstruktur der Anwendung durch das Hinzufügen entsprechender Nutzergruppen und ihrer Eigenschaften. Ein Journalnutzer gehört zu einer oder mehreren Nutzergruppen und hat diesbezüglich spezielle Zugriffsrechte auf die Kernobjekte der Anwendung. Durch das Personalisierungsmodell werden diese Informationen hinzugefügt.

Bei der Umsetzung des Informationsmodells mit WebRatio ist die Verwaltung der Nutzergruppen und ihrer Zugriffsrechte fest verankert. Jedem Projekt wird ein vordefiniertes Personalisierungssubschema zugewiesen, dass entsprechend eigener Anforderungen erweitert werden kann. Das Prinzip des Personalisierungsmodells wurde bereits in Kapitel 4.4.8 anhand des Registriervorgangs eines Autors erläutert.

Datenentwurf mit WebRatio

Mit dem Tool WebRatio wurde eine minimierte Variante des Datenschemas aus Abbildung 1 Anhang D umgesetzt. Die Modellierung der Datenstruktur wird optimal durch WebRatio unterstützt. WebRatio stellt alle notwendigen grafischen Notationen zur Modellierung eines Entity Relationship Modells bereit. Bei der Verbindung zweier Entitäten miteinander werden automatisch die zwei Beziehungsrollen der an der Beziehung beteiligten Entitäten im Projektbaum aufgelistet. Über das Eigenschaftenfenster können nun die Kardinalitäten der Beziehungsrollen angepasst, die Attributtypen der Attribute festgelegt und Ableitungsregeln für Beziehungen und Attribute erstellt werden.

Die Deklaration von abgeleiteten Beziehungen oder Attributen erfolgt über einen Derivation Wizard. Dieser unterstützt verschiedene Möglichkeiten der Ableitungsdefintion, indem er die bereits im Modell vorhandenen Entitäten, Beziehungen und Attribute so kombiniert, dass ohne Kenntnisse der Object Constraint Language (OCL) Ableitungsregeln gesetzt werden können. Abgeleitete Beziehungen werden im Datenschema durch eine gestrichelte Linie dargestellt. Im Projektbaum werden abgeleitete Attribute und Beziehungen farbig von den weiteren Attributen und Beziehungen unterschieden.

Abbildung 46 zeigt das mit WebRatio umgesetzte Informationsmodell in der grafischen Notation, die durch WebRatio zur Vergügung gestellt wird. Die Kardinalitäten sind in der Entity Relationship Notation zu sehen, da WebRatio diese Notation als Standard verwendet. Es ist dennoch möglich die Kardinalitäten in UML Notation anzuzeigen. Im Eigenschaftenfenster wird dann dennoch die ER Notation verwendet.

Figure 46. Vereinfachtes Informationsmodell mit WebRatio.

Vereinfachtes Informationsmodell mit WebRatio.

Data Mapping

In der Mapping View wird das Datenschema auf eine deklarierte Datenquelle abgebildet. Bevor das Data Mapping ausgeführt werden kann, muss eine leere Datenbank auf dem Server angelegt werden. In der Mapping View kann im Eigenschaftenfenster diese Datenquelle ausgewählt werden, um sie mit dem aktuellen Projekt zu verknüpfen. Für die Entwicklung des Online Journals wurde eine leere Access Datenbank Journals angelegt, sowie eine JDBC Verbindung, um darauf zugreifen zu können. Nach Auswahl des JDBC Treibers, in diesem Fall die Javasoft JDBC:ODBC Bridge, wird diese Datenbank mit WebRatio verbunden.

WebRatio transformiert das modellierte Datenschema in ein relationales Datenbankschema, indem spezifische Transformationsregeln angewendet werden. Der Entwickler kann zwischen der Erzeugung eines leeren Datenbankschemas und eines mit Beispieldaten gefüllten Datenbankschemas wählen. Für jedes Attribut, mit Ausnahme der OID, kann der Entwickler unterschiedliche Beispieldaten auswählen. Diese liegen in einer Textdatei vor, und sind abhängig vom Typ des jeweilgen Attributes. Das Mapping der abgeleiteten Attribute und Beziehungen kann vom Entwickler unabhängig vom grundlegenden Datenschema ausgeführt werden.

Der Prozess des Data Mapping muss nicht direkt nach der Erstellung des Datenschemas erfolgen. Der Entwurf des Hypertextmodells kann auch ohne das vorherige Abbilden der Daten erfolgen, da das Hypertextmodell mit den Entitäten des Datenschemas verknüpft ist. Nach eigenen Erfahrungen bei der Umsetzung des Online Journals ist es aber sinnvoll, das Data Mapping vor der Erstellung des Hypertextmodells durchzuführen. Fehler, die während des Data Mappings auftreten, haben meist eine Veränderung des Datenschemas zur Folge. Je größer diese Veränderungen sind, desto aufwendiger ist die Anpassung des bereits entworfenen Hypertextmodells, da dieses direkt mit den Entitäten und Attributen des Datenschemas arbeitet. Ein weiterer Vorteil des vorherigen Data Mapping ist, dass Teile der Anwendung während der Erstellung des Hypertextmodells bereits getestet werden können.

Umsetzung des Hypertextentwurfs

Während der Phase des Hypertextentwurfs wird die Funktionalität der Webanwendung auf Basis des Informationsmodells, der Hypertext View Beschreibungen und der funktionalen Anforderungen modelliert. Anhand des Hypertextmodells setzt der Entwickler in der Implementierungsphase das Modell in ausführbaren Programmcode um. Bei der Verwendung von WebRatio fällt diese zeitaufwendige Phase aufgrund der automatischen Quellcodegenerierung weg.

Die Modellierung des Hypertextmodells erfolgt wieder in der Editing View. WebRatio stellt alle durch WebML zur Verfügung gestellten Konzepte in grafischer Form bereit. Der erste Schritt bei der Hypertextmodellierung ist die Erstellung der 5 definierten Hypertext Views und deren grobe Gliederung durch Areas und Pages. Durch die Festlegung der Sichtbarkeitseigenschaften der Areas und Pages (home, default, landmark) kann so die Menüstruktur festgelegt werden.

Abbildung 47 zeigt die Gliederung der Hypertext View Journal Web der Nutzergruppe Leser. Das Hypertextmodell dieser Nutzergruppe enthält die Areas Contributions, Issues, Topics, Authors, Registration und Journal information, die alle als landmark definiert sind und damit im übergeordneten Menü sichtbar werden. Die Area Contributions enthält vier weitere als landmark definierte Pages By Rubric, By Keywords, By Author und Search. Diese sind als Untermenü des übergeordneten Menüpunktes Contributions sichtbar. In weiteren Verfeinerungsschritten werden nach und nach die notwendigen Content Units in den Pages platziert und durch Links miteinander verknüpft.

Figure 47. Gliederung der Hypertext View für die Nutzergruppe Leser.

Gliederung der Hypertext View für die Nutzergruppe Leser.

Die Einarbeitung in die Funktionsweise von WebRatio und die Konzepte der Hypertextmodellierung ist sehr aufwendig. Üblicherweise soll die automatische Quellcodegenierung erst nach Fertigstellung eines ersten Prototypen der Anwendung erfolgen. Um die Konzepte von WebML und ihre Umsetzung mit WebRatio besser zu verstehen, war es hilfreich, die Quellcodegenerierung schon sehr früh anzuwenden. Nur so ist es möglich, Fehler in der Modellierung zu entdecken, die aufgrund mangelnder Erfahrung im Umgang mit WebRatio und den Konzepten von WebML schnell entstehen können. Ausserdem kann so schrittweise die Anwendung aufgebaut werden. Die Generierung des Quellcodes erst nach Fertigstellung eines Prototyps, setzt viel Erfahrung bei der Erstellung des Hypertextmodells und der Content Management Modellierung voraus. Die Phasen Hypertextentwurf und Implementierung wurden während der Entwicklung des Online Journals sozusagen parallel durchgeführt.

Damit Quellcode generiert werden kann, muss jeder Hypertext View ein Layout zugewiesen werden. WebRatio stellt dafür einige vordefinierte Layouts bereit. Die Umsetzung der Präsentationsmodellierung ist Thema von Kapitel 5.7.

Es sind somit 4 Schritte erforderlich, bevor WebRatio die automatische Quellcodegenerierung durchführt:

  • Entwurf des Informationsmodells

  • Data Mapping

  • Entwurf eines Hypertextmodellausschnitts

  • Stylesheet - Zuweisung

Unterschiede in der grafischen Notation der WebML Elemente

WebRatio stellt alle Elemente zur Modellierung eines Hypertextmodells, sowie des Content Management Modells bereit. WebRatio verwendet dabei teilweise andere grafische Notationen als die in [CeriFrat03] für WebML vorgestellten Notationen.

Pages und Areas

Die Abbildung 48 stellt die übliche WebML-Notation und die in WebRatio verwendete Notation für Areas und Pages gegenüber. Die farbliche Hervorhebung der Areas gegenüber den enthaltenen Pages macht das Modell besser lesbar. Ausserdem sind die nutzerdefinierten Namen der Areas und Pages vom restlichen Bereich abgetrennt.

Figure 48. Grafische Notation von Areas und Pages a) in üblicher WebML Notation b) in WebRatio.

Grafische Notation von Areas und Pages a) in üblicher WebML Notation b) in WebRatio.

Links

Die grafische Notation der verschiedenen Linkarten unterscheidet sich in WebRatio ebenfalls von der vorgestellten WebML-Notation. Abbildung 49 stellt die übliche WebML-Notation und die von WebRatio verwendete Notation für die unterschiedlichen Links gegenüber. Einfache und transportierende kontextabhängige Links werden nicht unterschiedlich dargestellt. Automatische Links haben in WebRatio die gleiche grafische Notation wie einfache kontextabhängige Links. Die Zuweisung des Linktyps (normal, transport, automatic) erfolgt im Eigenschaftenfenster. Im Modell selbst können daher normale Links nicht von automatischen Links unterschieden werden. Die OK-links und KO-links der Operation Units werden in WebRatio durch grüne und rote Pfeile dargestellt. Dies ist beim Entwurf des Hypertextmodells von Vorteil, da farbliche Unterschiede in einem komplexen Modell eher wahrgenommen werden als unterschiedliche Linkbeschriftungen. Dieser Aspekt macht ein komplexes Hypertextmodell übersichtlicher und vor allem lesbarer, da die Links der Content Units sich ebenfalls von den Links der Operation Units abheben.

Figure 49. Grafische Notation von Links a) in üblicher WebML Notation b) in WebRatio.

Grafische Notation von Links a) in üblicher WebML Notation b) in WebRatio.

Nachträgliche Anpassung des Datenschemas

Während der Modellierung des Hypertextmodells kommt es oftmals vor, dass für die Umsetzung gewisser Funktionen Attribute benötigt werden, die noch nicht im Datenschema enthalten sind. Ein Beispiel dafür ist die Modellierung des Ablaufs eines Gutachtenprozesses. Beiträge durchlaufen hierbei mehrere Zustände, die in der Anwendung umgesetzt werden müssen. Zur Umsetzung unterschiedlicher Zustände wurde das Attribut status in die Entität Contribution eingefügt. Ein Beitrag kann sich in einem Gutachtungsprozess befinden, und bekommt den status inreview zugewiesen. Ein Beitrag der veröffentlicht wurde hat dagegen den status public, bzw. ein gelöschter Beitrag den status delete. Nachdem ein neues Attribut eingefügt wurde, muss das Data Mapping neu erfolgen. Nachteilig hierbei ist, dass die bereits vorhandenen Datenbanktabellen nicht aktualisiert werden, sondern ein komplett neues Datenbankschema erstellt werden muss. Bereits vorhandene Testdaten gehen dabei verloren. Die nun überflüssigen veralteten Tabellen müssen per Hand entfernt werden.

Umsetzung komplexer Datenbankabfragen

Die Umsetzung verschachtelter Suchabfragen in der Datenbank ist mit WebRatio und den Konzepten von WebML sehr aufwendig. Abfragemuster, die Eigenschaften mehrerer Entitäten, also mehrerer Datenbanktabellen verwenden, können nur durch die Kombination einer entsprechenden Anzahl von Content Units und Links umgesetzt werden.

Die Anwendung einer einfachen Sortierbedingung, in der Attribute anderer Entitäten verwendet werden sollen, ist nur durch die Anpassung des Datenschemas umsetzbar. Eine Index Unit ermöglicht die Angabe einer Sortierbedingung order by für die enthaltenen Objekte der zugewiesenen Entität. Ein Beispiel hierfür ist die Auflistung der veröffentlichten Beiträge des Online Journals. Für die Sortierbedingung order by können nur die Attribute der zugewiesenen Entität verwendet werden. Jeder Beitrag dieses Online Journals ist genau einer Rubrik zugeordnet. Rukriken werden durch eine eigenständige Entität Rubric modelliert., die über eine Beziehung mit der Entität Contribution verbunden ist. Die Sortierung der Beiträge nach zugehöriger Rubrik ist ohne weiteres nicht möglich.

Um eine solch einfache Sortierbedingung umsetzen zu können, muss wieder das Datenschema entsprechend angepasst werden. Hierzu wird das Attribut rubric als abgeleitetes Attribut zur Entität Contribution hinzugefügt, indem es aus der Entität Rubric als Fremdattribut importiert wird.

Abbildung 50 zeigt einen Auschnitt aus dem mit WebRatio umgesetzten Hypertextmodell der Hypertext View Journal Web der Nutzergruppe Leser. Hier ist nochmals die Modellierung des Registrierungsprozesses eines Autors dargestellt, sowie die Home Page und die Login Page dieser Sicht. Abbildung 51 zeigt die daraus generierte Anwendung mit Sicht auf die Page Registration der Area Registration.

Figure 50. Ausschnitt aus dem Hypertextmodell der Hypertext View von Nutzergruppe Leser.

Ausschnitt aus dem Hypertextmodell der Hypertext View von Nutzergruppe Leser.

Figure 51. Generierte Anwendung mit Area Registration aus Abbildung 50 .

Generierte Anwendung mit Area Registration aus Abbildung 50 .

Umsetzung des Präsentationsentwurfs

Die Umsetzung des Layouts einer Webanwendung erfolgt unabhängig von der Modellierung der Daten und Funktionen. In der Presentation View von WebRatio werden im Projekt-Baum alle definierten Hypertext Views mit zugehörigen Areas und Pages des Projektes aufgelistet. Bevor WebRatio überhaupt das Hypertextmodell in Quellcode transformieren kann, müssen die einzelnen Content Units in den entsprechenden Pages positioniert werden.

Abbildung 52 zeigt die grafische Oberfläche der Presentation View für die Page selected Contribution der Area Contributions. In der Arbeitsebene erfolgt die Platzierung der Content Units. Jede Page wird dabei als Gitter dargestellt. In die einzelnen Zellen des Gitters können die rechts neben dem Gitter aufgelisteten Content Units platziert werden. Dies erfolgt, indem sie einfach in die jeweilige Zelle hineingezogen werden. Content Units, die nicht in der Page positioniert wurden, sind nach der Generierung der Anwendung nicht sichtbar.

Jeder Hypertext View kann ein individuelles XSL Stylesheet zugewiesen werden. WebRatio stellt mehrere vordefinierte XSL Stylesheets zur Verfügung. XSL Stylesheets enthalten Präsentationsregeln, die benötigt werden, um die einzelnen Page Templates zu generieren. Sie legen fest in welcher Weise das Seitenlayout und die verschiedenen Typen der Content Units grafisch repräsentiert werden. Ebenso wie einer kompletten Hypertext View, kann auch jeder Area, Page, Content Unit und auch jedem Attribut ein eigenes XSL Stylesheet zugeordnet werden. Zu jedem Stylesheet gehören oftmals zusätzliche Page Layouts, die es ermöglichen, innerhalb eines Stylesheets zwischen unterschiedlichen Designvarianten zu wählen.

Die vordefinierten XSL Stylesheets können entsprechend eigenen Vorstellungen bearbeitet werden. Ebenso ist es möglich, eigene definierte Stylesheets in WebRatio einzubinden.

Für die Umsetzung dieses Online Journals wurde das vordefinierte Stylesheet Folder mit dem Page Layout blue gradient verwendet.

Figure 52. Presentation View von WebRatio für Page: selected Contribution.

Presentation View von WebRatio für Page: selected Contribution.

Bei der Generierung der Anwendung werden für die sichtbaren Attribute der einzelnen Content Units die Attributnamen aus dem Datenschema verwendet. Die Attributnamen einer Entität des Datenschemas besitzen meist keine allgemein gebräuchliche Schreibweise. Beispiel hierfür ist das abgeleitete Attribut NrOfContr, welches die bisher eingereichten Beiträge eines Autors darstellt.

Die einzelnen Content Units werden grafisch als, eine von den anderen Content Units abgegrenzte, Einheit dargestellt. So ist es nicht möglich Attribute unterschiedlicher Content Units und somit unterschiedlicher Objekte frei anzuordnen. Die Attribute sind demnach genau in der Reihenfolge zu sehen, wie sie für die entsprechende Content Unit im Hypertextmodell definiert wurden. Dies sind Aspekte die es verhindern, anhand der vordefinierten Stylesheets, ein wirklich ansprechendes und den individuellen Bedürfnissen einer Anwendung entsprechendes Layout zu generieren. Eine Nachbearbeitung des Layouts ist daher oftmals notwendig. Dies kann durch die Verwendung typischer WYSIWYG (What You See Is What You Get) Tools erfolgen, um das Layout und die Grafiken anzupassen oder um statischen Inhalt in die Page einzufügen.

Jede Webanwendung enthält üblicherweise Informationen wie Benutzungshinweise oder allgemeine Informationen, die nicht in einer Datenbank verwaltet werden. WebRatio bietet nicht die Möglichkeit solchen statischen Inhalt in die Anwendung einzubauen. Dieser Aspekt macht eine Nachbearbeitung der Webanwendung, nach der automatischen Quellcodegenerierung, ebenfalls notwendig.

Abschließende Bewertung

Abschließend werden in diesem Kapitel die Erfahrungen bei der Anwendung und Umsetzung von WebML in Verbindung mit dem CASE Tool WebRatio dazu verwendet, um eine Bewertung bezüglich folgender Kriterien vorzunehmen:

  • Notwendigkeit

  • Integrierbarkeit

  • Erlernbarkeit

  • Umsetzbarkeit

  • Entwicklungsaufwand

Notwendigkeit

Bereits in der Einleitung dieser Arbeit wurde die Notwendigkeit einer modellbasierten Modellierungssprache für die konzeptionelle Beschreibung der webspezifischen Anforderungen und Eigenschaften datenintensiver Webanwendungen kurz erläutert. Die Entwicklung komplexer datenintensiver Webanwendungen erfordert eine gut konzipierte Planung. Die bisher verwendeten Entwurfsmethoden von datenintensiven Webanwendungen bieten nicht die Möglichkeit der modellbasierten Beschreibung webspezifischer Eigenschaften wie:

  • Hypertextgliederung

  • Webseitentopologie

  • Datenstrukturierung

  • Navigationseigenschaften

Die Modellierungskonzepte von WebML greifen genau diesen Aspekt heraus. Durch die Hypertextmodellierung, das heisst anhand des Hypertextmodells und Content Management Modells, können diese wesentlichen Eigenschaften datenintensiver Webanwendungen konzeptionell beschrieben werden. Den Entwicklern wird damit ein Werkzeug gegeben, eine Webanwendung mit ihren funktionalen Anforderungen auf abstrakter Ebene komplett zu modellieren. Dies hat einen großen Vorteil für die anschließende Implementierungsphase. Der Programmierer kann nun anhand des entworfenen Hypertextmodells ein genaues Bild von der zu entwickelnden Webanwendung bekommen. Er muss nicht auf oftmals unzureichende schriftliche Beschreibungen oder Zeichnungen zurückgreifen, die die Anforderungen der Anwendungsstrukturierung und des Layouts betreffen.

Ein weiterer wichtiger Aspekt, der die Notwendigkeit hervorhebt, ist die Wartung und Weiterentwicklung einer komplexen Webanwendung. Bestehende Webanwendungen müssen oftmals an neue Anforderungen angepasst werden. Steht nun eine konzeptionelle Beschreibung der Webanwendung zur Verfügung, wird die Weiterentwicklung einer Anwendung erheblich vereinfacht, denn so können auch technisch weniger versierte Mitarbeiter an der Weiterentwicklung mitwirken und sind nicht daran gebunden, direkt mit dem Programmcode zu arbeiten.

Die Verwendung des CASE Tools WebRatio unterstützt die Entwicklung einer Webanwendung, indem zum einen der komplette Modellentwurf mit dem Programm vorgenommen werden kann, und zum anderen die Implementierungsphase automatisiert wird, und damit der gesamte Entwicklungsprozess erheblich beschleunigt wird.

Integrierbarkeit

Die Modellierungskonzepte von WebML orientieren sich an den konventionellen Entwurfsmethoden der Softwaremodellierung und lassen sich daher gut in den bisherigen Entwicklungsprozess einer Webanwendung einbinden. Die bisherige Vorgehensweise umfasst die Beschreibung der funktionalen Anforderungen einer Webanwendung, sowie den Entwurf des Datenschemas. Der Entwicklungsprozess für die Entwicklung datenintensiver Webanwendungen orientiert sich an dieser Vorgehensweise und erweitert den Prozess durch eine zusätzliche Entwurfsphase, den Hypertextentwurf.

Die Einführung der in dieser Arbeit beschriebenen neuen Modellierungskonzepte in Unternehmen, erfordert somit keine komplette Umorientierung, sondern schließt an die bisherigen Kenntnisse und Erfahrungen der Mitarbeiter an.

Durch die Verwendung von WebRatio wird die Integration der Modellierungsmethodik von WebML und damit der Einarbeitungsprozess nochmals erleichtert, da der komplette Entwurf einer Webanwendung durch dieses Tool unterstützt und die Entwicklung der Webanwendung beschleunigt wird.

Erlernbarkeit

Die neu eingeführten Konzepte von WebML stellen grafische Notationen bereit, die intuitiv verständlich sind und den Lernprozess diesbezüglich erleichtern. Die Modellierung einfacher Anforderungen einer Webanwendung lassen sich relativ schnell umsetzen. Um einen komplexen Hypertext einer Webanwendung nach bestimmten Anforderungen zu entwerfen, benötigt es einer erheblichen Einarbeitungszeit in die verschiedenen Möglichkeiten der Verwendung der verschiedenen Content und Operation Units, sowie deren Kombination und Verbindung durch Links.

Die Einarbeitung in WebRatio selbst erfordert ebenfalls einen längeren Lernprozess, um damit ein komplexeres Projekt umsetzen zu können. Dazu gehört vor allem der Prozess des Data Mappings, die Erstellung verschiedener Hypertext Views und damit die praktische Umsetzung der theoretisch vorgestellten Modellierungskonzepte, die Einarbeitung in das Verfahren der Präsentationsmodellierung, sowie die automatische Generierung des Quellcodes. WebRatio ist ein sehr komplexes Programm, dessen richtige Anwendung und Funktionsnutzung erst nach einiger Erfahrung und Übung verinnerlicht werden kann.

Die Verwendung von WebRatio unterstützt den Lernprozess der Modellierungskonzepte von WebML aufgrund einer Vielzahl von zur Verfügung gestellten Dokumentationen und Tutorials, die in die Modellierung des Hypertextmodells und Content Management Modells einweisen.

Unternehmen, die diese Modellierungsmethodik gemeinsam mit dem CASE Tool WebRatio einführen wollen, sollten eine längere Phase der Einarbeitung in Kauf nehmen.

Nach einiger Einarbeitungszeit und Erfahrungssammlung stellt WebML vor allem in Verbindung mit der Verwendung von WebRatio eine große Weiterentwicklung und Unterstützung des Entwicklungsprozesses einer datenintensiven Webanwendung dar.

Umsetzbarkeit

WebML bietet die Möglichkeit, die wichtigsten Eigenschaften von datenintensiven Webanwendungen zu modellieren. In Verbindung mit WebRatio wird den Entwicklern eine umfangreiche Entwicklungsumgebung zur Verfügung gestellt, die die Modellierungsmethodik von WebML unterstützt.

WebML stellt Notationen bereit, mit deren Hilfe typische Anforderungen und Funktionen datenintensiver Webanwendungen entworfen werden können. Dazu zählen typische Datenbankabfragen, wie die Auflistung und Anzeige bestimmter Datenobjekte, oder die Veränderung der Daten durch Operationen wie das Anlegen, Bearbeiten oder Löschen eines Datensatzes. Datenintensive Webanwendungen mit sehr individuellen Anforderungen oder komplexen Berechnungsfunktionen können nur ansatzweise mit Hilfe der bisher zur Verfügung gestellten WebML Elemente modelliert werden.

Eine durchaus sinnvolle Funktion datenintensiver Webanwendungen ist die automatische Druckfunktion bzw. die automatische Generierung einer Textdatei, um beispielsweise Produkt- oder Beitragslisten zu erzeugen. Die Umsetzung solcher individuelleren Anforderungen sind nicht mit den üblichen WebML Elementen umsetzbar.

WebML stellt ein Modellierungskonzept dar, welches durchaus erweiterbar ist, um individuellere Eigenschaften datenintensiver Webanwendungen zu modellieren. Hierfür bietet WebML die Möglichkeit erweiterte Operationen, sogenannte Generic Operation Units, zu definieren.

WebRatio unterstützt alle vorgestellten WebML Elemente und enthält sogar weitere nützliche Content Units und Operation Units, um weitere webspezifische Aspekte zu modellieren. Ein Beispiel hierfür ist die Operation Unit Change Group. Wie bereits erläutert, verwendet WebRatio ein vordefiniertes Personalisierungsmodell im Datenschema. Dieses sieht vor, dass Nutzer des Systems mehreren Nutzergruppen angehören können. Die Operation Unit Change Group ermöglicht es einem Nutzer, zwischen den ihm zugewiesenen Nutzergruppen zu wechseln, ohne sich erneut im System einloggen zu müssen.

Ein weiteres Beispiel ist die Time Unit. Bei der Aktivierung einer Time Unit enthält ihr Ausgabeparameter das aktuelle Datum bzw. den aktuellen Zeitstempel. Diese Funktion ist besonders bei der systemgebundenen Registrierung eines Nutzers oder der automatisierten Beitragsverwaltung in einem Online Journal einsetzbar, um das aktuelle Datum in einem versteckten Formularfeld abzulegen.

WebRatio ermöglicht es ebenfalls selbst definierte Units einzubinden. Diese müssen dann entsprechend der Anforderungen implementiert werden. Hier stellt sich die Frage, ob die zusätzlich benötigten Funktionen, die nicht mit WebRatio bzw. WebML umgesetzt werden können, durch nachträgliche Bearbeitung des Quellcodes dem Programm hinzugefügt werden sollten. Handelt es sich um Funktionen, die häufiger Verwendung finden könnten, dann sollten diese mit WebRatio umgesetzt werden. Handelt es sich um Anforderungen bzw. Funktionen die einmalig oder eher selten angewendet werden, sollte der Aufwand abgeschätzt werden und die Nachbearbeitung des Quellcodes unabhängig von WebRatio erfolgen.

Eine komplexe datenintensive Webanwendung mit speziellen funktionalen Anforderungen und individuellen Layoutvorstellungen, kann mit WebML und der Verwendung von WebRatio in einer ersten Grundversion erstellt werden. Eine Erweiterung des automatisch generierten Quellcodes ist in diesem Fall unumgänglich.

Entwicklungsaufwand

Das Ziel von WebML ist die Unterstützung des Entwurfs datenintensiver Webanwendungen durch die Erweiterung der bisher verwendeten Entwurfsmethoden. Die konzeptionelle Beschreibungsmöglichkeit der funktionalen Anforderungen, der Webseitentopologie und Navigationseigenschaften einer Webanwendung, durch das Hypertextmodell und Content Managementmodell, erhöht den Aufwand für den Entwurf der Webanwendung. Da aber nun ein konzeptionelles Modell vorhanden ist, das die gesamte Anwendung auf abstrakter Ebene beschreibt, wird der Entwicklungsprozess positiv beeinflusst. Die Implementierung der Webanwendung anhand eines konzeptionellen Modells beschleunigt den Entwicklungsprozess erheblich, da alle für die Implementierung notwendigen Informationen nun im Hypertextmodell vorhanden sind und nicht mehr, oftmals unzureichende, Beschreibungen und Zeichnungen als Grundlage dienen.

Zur Entwicklung einer datenintensiven Webanwendung gehört natürlich entsprechend unterstützende Software. Mit Hilfe von WebRatio kann der Entwicklungsprozess einer datenintensiven Webanwendung mehrfach beschleunigt werden. WebRatio vereinigt den gesamten Entwurfsprozess, sowie die darauf folgende Implementierungsphase in einem Programm. WebRatio greift zum einen die bewährten Entwurfskonzepte auf, indem das Datenschema in ER-Notation oder UML-Notation entworfen werden kann. Darauf aufbauend wird der komplette Entwurf des Hypertextmodells unterstützt. Weiterhin kann das Layout und die Webseitentopologie der Webanwendung mit WebRatio umgesetzt werden. Der bedeutendste Vorteil von WebRatio ist die Möglichkeit der automatischen Quellcodegenerierung. Dadurch wird der Entwicklungsaufwand erheblich verringert.

WebRatio dient somit der schnellen Entwicklung eines Prototypen der gewünschten Webanwendung, der anschließend nach individuellen Bedürfnissen nachbearbeitet werden kann. Die Nachbearbeitung und Erweiterung des automatisch generierten Quellcodes sollte im Hinblick des Entwicklungsaufwands nicht unterschätzt werden.

Bibliography

[CeriFrat03] Stefano Ceri, Piero Fraternali, Aldo Bongio, Marco Brambilla, Sara Comai, Maristella Matera. Designing Data-Intensive Web Applications, Morgan Kaufmann, Elsevier, 2003

[Balzert00] Helmut Balzert. Lehrbuch der Software - Technik, Software - Entwicklung, Spektrum 2. Auflage , 2000

[WebML] Stefano Ceri, Piero Fraternali, Aldo Bongio. Web Modeling Language (WebML): a modeling language for designing Web sites, http://www.webml.org/webml/upload/ent5/1/www9.pdf

Stefano Ceri, Piero Fraternali,Maristella Matera. Conceptual Modeling of data-intensive Web applications, http://www.webml.org/webml/upload/ent5/1/IC.pdf

[Web0]http://www.webml.org/webml/page3.do?ctx1=EN (Overview)

[Web1]http://www.webml.org/webml/page6.do?dau4.oid=2&UserCtxParam=0&GroupCtxParam=0&ctx1=EN (Data Model)

[Web2]http://www.webml.org/webml/page6.do?dau4.oid=4&inu4.current=4&UserCtxParam=0&GroupCtxParam=0&ctx1=EN (Hypertext Model)

WebML User Guide: webml_guide.pdf (WebRatio Dokumentation)

WebRatio User Guide: webratio_guide.pdf (WebRatio Dokumentation)

Tutorial 1 - Building Content Publishing Applications: content-publishing_tutorial.pdf

Tutorial 2 - Building Content Management Applications: content-management-tutorial.pdf

Tutorial 3 - Access Rights Management: access-rights_tutorial.pdf

WebRatio: http://www.webratio.org

[FQS] FQS, English: http://www.qualitative-research.net/fqs/fqs-eng.htm, German: http://www.qualitative-research.net/fqs/fqs.htm

http://gesj.internet-academy.org.ge/en/title_en.php?b_sec=&section_l=comp (Electronic Scientific Journal)

Open Access Journals: http://www.doaj.org

[wiki0] http://de.wikipedia.org/wiki/Hypertext , 04.03.06

A. Eidesstattliche Erklärung

Ich erkläre hiermit an Eides statt, dass ich die vorliegende Bachelorarbeit selbständig und ohne unerlaubte Hilfe angefertigt, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und die den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe.

Cottbus, 20.04.2006Freya Weiß

B. Abbildungsverzeichnis

Abbildung 1Phasen des Entwicklungsprozesses einer Webanwendung und Bezug zu den Modellen der WebML, nach ([CeriFrat03] S. 197 Abb. 6.2)
Abbildung 2Modelle der Webmodellierungssprache WebML
Abbildung 3Grafische Notation der Entitäten: Author, Contribution, Topic
Abbildung 4Grafische Notation der Entitäten mit Attributen und Schlüsselattributen
Abbildung 5Grafische Notation der Entitäten Author, Contribution und Topic mit Atrtributen, Attributtypen und Beziehungen
Abbildung 6Generalisierungshierarchie / Spezialisierung
Abbildung 7Hauptelemente des Hypertextmodells
Abbildung 8Grafische Notation (in WebML Syntax) einer Hypertext View mit 2 Areas und 5 Pages
Abbildung 9Grafische Notation: verschachtelte AND sub-pages
Abbildung 10Grafische Notation: AND sub-pages und OR sub-pages
Abbildung 11Grafische Notation der Data Unit AuthorInfo mit zugehöriger Entität
Abbildung 12Alternative UML-Syntax einer Data Unit allgemein und speziell für Data Unit AuthorInfo
Abbildung 13Grafische Notation der Multidata Unit Contributions mit zugehöriger Entität
Abbildung 14Alternative UML-Syntax einer Multidata Unit allgemein und speziell für Multidata Unit Contributions
Abbildung 15Grafische Notation der Index Unit a) und Multichoice Index Unit b) RubricList mit zugehöriger Entität
Abbildung 16Alternative UML-Syntax der Index Unit a) und Multichoice Index Unit b) RubricList
Abbildung 17Grafische Notation einer Hierarchical Index Unit in WebML Syntax
Abbildung 18Grafische Notation der Hierarchical Index Unit RubricList mit zugehörigen Entitäten
Abbildung 19Alternative UML-Syntax einer Hierarchical Index Unit allgemein und speziell für die Hierarchical Index Unit RubricList
Abbildung 20Grafische Notation der Scroller Unit AuthorScroll in Verbindung mit der DataUnit AuthorInfo, in WebML Syntax
Abbildung 21Alternative UML-Syntax einer Scroller Unit allgemein und speziell für die Scroller Unit AuthorScroll zusammen mit Data Unit AuthorInfo
Abbildung 22Grafische Notation der Entry Unit AuthorInput in WebML Syntax
Abbildung 23Alternative UML-Syntax einer Entry Unit allgemein und speziell für die Entry Unit AuthorInput
Abbildung 24Beispiel eines kontextunabhängigen Links
Abbildung 25Beispiel einfacher kontextabhängiger Links
Abbildung 26Beispiel eines automatischen kontextabhängigen Links
Abbildung 27Beispiel eines transportierenden Links
Abbildung 28Linkparameter und parametrischer Selektor eines einfachen kontextabhängigen Links
Abbildung 29Grafische Notation eines mehrwertigen Linkparameters
Abbildung 30Beispiel für Linkparameter des ausgehenden Links der Entry Unit ByTitle
Abbildung 31Grafische Notation einer Set Unit
Abbildung 32Grafische Notation einer Get Unit
Abbildung 33Grafische Darstellung einer Create Unit in Verbindung mit einer Entry Unit und Data Unit
Abbildung 34Grafische Darstellung zur Anwendung einer Delete Unit
Abbildung 35Ausschnitt aus Informationsmodell mit den Entitäten Contribution, Review und Reviewer
Abbildung 36Grafische Darstellung einer Modify Unit in Verbindung mit einer Entry Unit und Data Unit
Abbildung 37Grafische Darstellung einer Connect Unit
Abbildung 38Erweiterte grafische Darstellung zur Anwendung einer Connect Unit
Abbildung 39Erweiterte grafische Darstellung zur Anwendung einer Disconnect Unit
Abbildung 40Grafische Darstellung zur Anwendung einer Login Unit
Abbildung 41Grafische Darstellung zur Anwendung einer Logout Unit
Abbildung 42Ausschnitt des Informationsmodells: Personalisierungsmodell des modellierten Journals
Abbildung 43Grafische Darstellung einer Transaction am Beispiel der Registrierung eines neuen Autors
Abbildung 44Gliederung der grafischen Oberfläche von WebRatio
Abbildung 45Generalisierungshierarchie der Nutzergruppen des Online Journals
Abbildung 46Vereinfachtes Informationsmodell mit WebRatio
Abbildung 47Gliederung der Hypertext View für die Nutzergruppe Leser
Abbildung 48Grafische Notation von Areas und Pages a) in üblicher WebML Notation b) in WebRatio
Abbildung 49Grafische Notation von Link a) in üblicher WebML Notation b) in WebRatio
Abbildung 50Ausschnitt aus dem Hypertextmodell der Hypertext View von Nutzergruppe Leser
Abbildung 51Generierte Anwendung mit Area Registration aus Abbildung 50
Abbildung 52Presentation View von WebRatio für Page: selected Contribution
Abbildung 1 Anhang DInformationsmodell des Online Journals (Partizipationssemantik)

C. Abkürzungsverzeichnis

JSPJava Server Pages
CASEComputer Aided Software Engineering
XMLExtensible Markup Language
XSLExtensible Stylesheet Language
XSLTXSL Transformations
OCLObject Constraint Language
UMLUnified Modeling Language
HTMLHypertext Markup Language
WYSIWYGWhat You See Is What You Get
WebMLWeb Modeling Language

D. Weitere Modellierungsdokumente

Figure D.1. Informationsmodell des Online Journals (Partizipationssemantik)

Informationsmodell des Online Journals (Partizipationssemantik)