Funktionale Spezifikation von Websites - Journals

Eine strikte Trennung der Belange verhilft zu mehr ¨Uberblick. Wir unterteilen die ..... licher Mitarbeiter am Institut für Softwaretechnik der Universität.
656KB Größe 10 Downloads 207 Ansichten
Funktionale Spezifikation von Websites Torsten Gipp Universit¨at Koblenz-Landau [email protected] Abstract: Websites sind komplexe Software-Artefake, deren Erstellung und Pflege ohne ein wichtiges Hilfsmittel nicht mehr m¨oglich ist: Abstraktionen, Modelle. Der vorliegende Text beschreibt einen Ansatz, nach dem ein großer Teil der Modelle als funktionale Programme erstellt werden. Hierdurch werden die Modelle zu ausdrucksstarken Spezifikationen, die sogar direkt ausgef¨uhrt werden k¨onnen. Zur Implementierung verwenden wir die weit verbreitete funktionale Programmiersprache Haskell.

1

¨ Einfuhrung

Eine Website, auch Web-Pr¨asenz genannt, ist eine Sammlung einzelner, miteinander durch Hyperlinks verkn¨upfter Dokumente, die mit Hilfe von Web-Technologien von einem Server zur Verf¨ugung gestellt und mit einem Webbrowser abgerufen und angezeigt werden k¨onnen. Die Erstellung einer solchen Website ist eine große Herausforderung. Realistisch große Websites zu erstellen ist ohne technische Hilfsmittel kaum m¨oglich. Hier ist ein wohl-strukturiertes Vorgehen erforderlich, um der Komplexit¨at Herr zu werden. Die Qualit¨atsanforderungen an eine Website sind sehr hoch. Sie soll in der Regel einem großen Publikum zug¨anglich gemacht werden, so dass von einem Fehler viele Benutzer betroffen w¨aren. Insbesondere bei sicherheitskritischen Anwendungen steht die Qualit¨at ganz besonders im Vordergrund, zum Beispiel bei Websites, mit denen finanzielle Transaktionen get¨atigt werden. Gleichzeitig mit der Erf¨ullung der Qualit¨atsanforderungen wird eine immer k¨urzere Entwicklungszeit gefordert, und es muss gew¨ahrleistet sein, dass Erweiterungen schnell vorgenommen werden k¨onnen. All diesen Anforderungen l¨asst sich nur mit soliden, ingenieurm¨aßigen, softwaretechnischen Verfahren und Methoden begegnen. Ein g¨angiges Vorgehen besteht in der Verwendung von Modellen, also zweckbezogenen Abstraktionen. Die Idee besteht darin, das gew¨unschte Endprodukt auf einer abstrakten Ebene zu beschreiben und die gew¨unschte Website aus diesen Beschreibungen automatisiert zu generieren (vgl. z.B. [KPRR04]). Der in diesem Text vorgestellte Ansatz vereint nun die Vorteile des Modell-basierten Vorgehens mit denen der funktionalen Programmiersprachen. Dies sind Programmiersprachen, die dem funktionalen Paradigma folgen, also Algorithmen ausschließlich in Form von (mathematischen) Funktionen beschreiben. Die Zusammenf¨uhrung der Modell-basierten und der funktionalen Sicht ist der Kerngedanke dieser Arbeit, vorgestellt in der Dissertation [Gip06]. Darauf sei auch f¨ur weiterf¨uhrende Informationen verwiesen, da sich der

Torsten Gipp

91

Abbildung 2: Eingabe der Reisedaten (Seite TripDescription)

flughafen. Auf der Seite TripList bekommt er dann eine Liste mit m¨oglichen Fl¨ugen pr¨asentiert, von denen er sich einen ausw¨ahlen kann. Auf der Seite TripDetails findet er dann weitere Informationen zu dem ausgew¨ahlten Flug. Ist er zur Buchung bereit, werden die abschließenden Schritte auf den Seiten BillingDetails und OrderConfirmation abgearbeitet. Die einzelnen Seiten sind aus Bausteinen zusammen gesetzt, wie z.B. Textbl¨ocke, Bilder oder Eingabeformulare. Die Seite TripDescription enth¨alt beispielsweise ein solches Formular. Es ist in Abbildung 2 zu sehen. Das Formular wird aus einer abstrakten Beschreibung heraus generiert, die in Form eines funktionalen Programms vorliegt. Hier der Code: tasTripDescriptionForm :: StatefulPageFunc tasTripDescriptionForm = do (graph, session) ← get return $ Form ”TripDescriptionForm” [] [ Text ”From:” , Field ”originCity” [] (OptionListField $ getOriginCities graph) [] ”” , Text ”To:” , Field ”destCity” [] (OptionListField $ getDestCities graph) [] ”” , Text ”Departure:” , Field ”dateOfDeparture” [] SimpleField [] ”” ¨ −− einige ahnliche Zeilen ubersprungen ¨ , Text ”Sorting Order:” , Field ”sortingPreference” [] (OptionListField $ map show possibleTripSortingPreferences) [] ”” , Field ”submit” [] SubmitField [] ”” ] tasTripList []

(1) (2)

Die Bestandteile des Formulars, z.B. die Texte und die Eingabefelder, finden sich im Code wieder. Auf die Syntax kann an dieser Stelle aus Platzgr¨unden nicht weiter eingegangen werden. Die formale Repr¨asentation hat einige entscheidende Vorteile. Sie erschließen sich aus der M¨achtigkeit der funktionalen Programmiersprache, die beispielsweise an jeder Stelle beliebige Funktionsaufrufe erlaubt, und dem Zusammenspiel mit den anderen Beschreibungen. Zudem kann das Formular direkt aus der formalen Beschreibung erzeugt werden und die Beschreibung ist sehr nahe an der Aufgabenstellung. Im folgenden Abschnitt finden Sie eine Gesamt¨ubersicht u¨ ber die angesprochenen Vorteile.

92

3

Functional Web Site Specification

¨ des vorgestellten Ansatzes Vorzuge

Die Kombination der modellbasierten Sichtweise und der funktionalen Programmiersprachen hat insbesondere folgende Vorz¨uge (vgl. [GE07]): • Deklarative Beschreibungen in Verbindung mit Modellen erm¨oglichen ausf¨uhrbare Spezifikationen. Die funktionalen Programme, die wir verwenden, um die einzelnen Teile der Website zu beschreiben, sind gleichzeitig ihre Spezifikation. In Kombination mit den Modellen sind die Programme ausf¨uhrbar und ihre Ausf¨uhrung ergibt als Resultat die gew¨unschte Website. Dies ist m¨oglich, weil die Spezifikation hinreichend pr¨azise ist. • Die Formalisierung der Anforderungen erfolgt in m¨oglichst fr¨uhen Phasen. Wir schlagen vor, die Anforderungen (requirements) an die Website so fr¨uh wie m¨oglich zu formalisieren, d.h. so pr¨azise wie m¨oglich zu notieren. Dies verhindert eine Abweichung der Spezifikation von den Anforderungen. So wird die Website sp¨ater auch tats¨achlich so, wie es die Anforderungen vorsehen. Die Formalisierung erfolgt zudem deklarativ, so dass sich viele Anforderungen ohne großen Aufwand formalisieren lassen. • Es k¨onnen jederzeit neue Abstraktionsebenen eingef¨uhrt werden. Der Komplexit¨at einer Website kann nur durch Abstraktion begegnet werden. Funktionale Programmiersprachen haben genau hier eine ihrer St¨arken, denn es ist sehr einfach, jederzeit neue Abstraktionen selbst zu definieren. Ein Beispiel sind Funktionen h¨oherer Ordnung, mit denen beispielsweise eigene Kontrollstrukturen definiert werden k¨onnen. Auch Bibliotheken mit Kombinatoren (z.B. [Han06]) und so genannte “domain-specific embedded languages” (DSEL) (z.B. [Thi05]) helfen dabei, Abstraktionen zu schaffen und unn¨otige Implementierungs-Details zu verbergen. ¨ • Eine strikte Trennung der Belange verhilft zu mehr Uberblick. Wir unterteilen die Modellierungsaufgabe in sechs Teile, n¨amlich in den Content, die Navigation, die Seiten, die Queries und Updates, die Pr¨asentation und die Dynamik. So kann den spezifischen Herausforderungen der einzelnen Teile besser begegnet werden. • Unterst¨utzung f¨ur Tests und Simulation. Funktionale Programme lassen sich sehr gut testen. Testf¨alle lassen sich direkt aus den Anforderungsdokumenten herleiten. Gleichfalls ist eine Simulation des Benutzerverhaltens realisierbar, denn die einzelnen Schritte bei der Bedienung einer Website sind nichts anderes als eine Folge von Funktionsaufrufen mit konkreten Parametern.

Torsten Gipp

93

ruft

PräsentationsFunktion

ruft DynamikFunktion

ruft

SeitenFunktion

bezieht sich auf

NavigationsStruktur

ruft

ruft

Query, Update Funktion bezieht sich auf

bezieht sich auf

Content

¨ Abbildung 3: Uberblick u¨ ber die Modelle. Nach: [Gip06, S. 60]

4

Vorstellung der Modelle

Wir unterteilen die Modellierung einer Website, dem Prinzip der “Trennung der Belange” folgend, in sechs verschiedene Teilmodelle. Abbildung 3 zeigt die Teilmodelle und ihren Zusammenhang. Jedes Rechteck repr¨asentiert ein Teilmodell. Rechtecke mit abgerundeten Ecken stehen f¨ur ‘traditionelle’ konzeptuelle Modelle. Die normalen Rechtecke bezeichnen jeweils ein Modell, das als funktionales Programm vorliegt. Der Content (Inhalt) wird durch ein konzeptuelles Modell beschrieben. Man betrachtet dazu die Anwendungsdom¨ane und identifiziert die relevanten Konzepte und die Beziehungen zwischen ihnen. F¨ur die Beispielanwendung TAS sind Konzepte wie “Flugreise” oder “Kunde” relevant. Die Konzeptualisierung der Anwendungsdom¨ane hilft dabei, eine pr¨azise Begriffswelt zu schaffen, auf die die folgenden Modelle aufbauen k¨onnen. Die Navigationsstruktur definiert die Verkn¨upfung der einzelnen Seiten. Die Seiten sind das zentrale Element einer Website. Jede Seite ist durch eine Funktion definiert, deren Auswertung eine abstrakte Beschreibung der fertigen Seite ergibt. Die Funktion stellt die Seite aus einzelnen Fragmenten zusammen. Die Queries und Updates haben den Zweck, Inhaltsbausteine zu liefern bzw. Inhalte zu ver¨andern. Sie Seitenfunktionen greifen auf sie zur¨uck, um auf den Content zuzugreifen. Queries und Updates werden ebenfalls als Funktionen definiert. Die Pr¨asentation k¨ummert sich um die konkrete Darstellung der Website. Alle anderen Modelle behandeln die Website unabh¨angig von jedweden gestalterischen Aspekten. Die Pr¨asentation ist eine Abbildung der Seiten in ein konkretes Ausgabeformat und wird ebenfalls in Form einer Funktion notiert. Die Dynamik einer Website ist das Anwendungs-spezifische Verhalten, die so genannten “Gesch¨aftslogik”. F¨ur das TAS w¨are dies z.B. die Durchf¨uhrung einer Reisebuchung oder auch die G¨ultigkeitspr¨ufung der Eingaben des Kunden. Auch die Dynamik wird durch Funktionen repr¨asentiert.

94

4.1

Functional Web Site Specification

Content

Schemaebene. Es entspricht dem aktuellen Stand der Technik, die Schemaebene, also das eigentliche Content-Modell, mit Hilfe eines konzeptuellen Modells zu erfassen. In einem solchen Modell wird die Anwendungsdom¨ane durch Konzepte (Klassen) und Beziehungen zwischen ihnen repr¨asentiert. Als Notation haben sich UML Klassendiagramme durchgesetzt. Das Content-Modell definiert pr¨azise, welche Begriffe f¨ur die Anwendungsdom¨ane relevant sind und wie sie zusammen h¨angen. Durch das Modell wird die Struktur des Contents definiert, das (Typ-)Schema. Instanzebene. Bei der Modellierung einer Website wird in aller Regel vom eigentlichen, konkreten Inhalt abstrahiert. Die wesentlichen Aspekte werden vom Content-Modell auf Schemaebene ber¨ucksichtigt. Der Content selbst ist eine Instanz des Content-Modells. Unser Ansatz st¨utzt sich hierf¨ur auf Graphentechnologie. Der Content ist in einem typisierten Graphen gespeichert, dessen Typschema durch das Content-Modell vorgegeben ist. Graphen sind eine m¨achtige mathematische Struktur, und zeigen ihre St¨arke hier insbesondere beim Abfragen (Querying) der Inhalte, was ben¨otigt wird, um zu definieren, welche Inhalte auf den einzelnen Seiten zu sehen sein sollen. Das Querying wird durch die QueryFunktionen erledigt, die in Abschnitt 4.4 beschrieben werden.

4.2

Navigationsstruktur

Abbildung 1 zeigt die Navigationsstruktur f¨ur die Beispielanwendung. Es ist eine visuelle Repr¨asentation der Hyperlinkstruktur der Website. Jedes Rechteck steht f¨ur eine Einzelseite oder f¨ur eine Klasse von gleichartigen Seiten. Die durchgezogene Pfeile definieren eine Hierarchie unter den Seiten, die so genannte prim¨are Navigationsstruktur. Durch die Hierarchie gibt es einen eindeutigen Pfad von der Wurzel zu jeder Seite. Auch l¨asst sich anhand der Hierarchie automatisch ein “Inhaltsverzeichnis” (site map) der Website erzeugen. Gestrichelte Pfeile stehen f¨ur Hyperlinks, die unabh¨angig von der Hierarchie zwischen den Seiten existieren. Wir unterscheiden vier Arten von Seiten, die durch unterschiedliche Symbole kenntlich gemacht werden. Rechtecke mit einem Blitzsymbol stehen f¨ur dynamische Seiten, die ihren Inhalt dynamisch ver¨andern, also bei jeden Zugriff einen anderen Inhalt liefern. Rein statische Seiten haben ein undekoriertes Rechteck. Enth¨alt eine Webseite ein Formular, so markieren wir dies durch ein stilisiertes Formular im Rechteck. Schließlich gibt es noch das Symbol, das einen Stapel von Seiten darstellt. Dies repr¨asentiert virtuelle Seiten, die jeweils f¨ur eine ganze Klasse von Seiten stehen. In der Abbildung 1 ist dies beispielsweise CustomerHome(id). Diese steht f¨ur personalisierte Homepages f¨ur jeden Kunden. F¨ur jeden g¨ultigen Wert von id gibt es eine eigene Seiten-Instanz. Das Diagramm erlaubt die Notation von weiteren Angaben zu den Hyperlinks, insbesondere durch die Angabe von Berechtigungen zum Zugriff auf Seiten oder Bereiche.

Torsten Gipp

4.3

95

Seitenfunktionen

Der zentrale Baustein einer Website sind die einzelnen Seiten. In unserem Ansatz werden die Seiten durch Funktionen beschrieben. Ein kurzes Seitenfragment sahen Sie bereits in Abschnitt 2. Seitenfunktionen liefern eine abstrakte Repr¨asentation der endg¨ultigen Seite, die anschließend durch eine Pr¨asentationsfunktion (siehe Abschnitt 4.5) in die endg¨ultige Ausgabesprache u¨ berf¨uhrt wird. Wir nennen die abstrakte Repr¨asentation der Seiten APD (abstract page description) und nutzen den gleichnamigen Datentyp zur internen Darstellung. Eine Seitenfunktion liefert also einen Term vom Typ APD. Das Zusammenf¨ugen einer Seite aus einzelnen Bausteinen kann mit der funktionalen Programmiersprache auf sehr pr¨azise und einfache Weise erfolgen. Gleichzeitig kann jederzeit die volle M¨achtigkeit der Sprache ausgenutzt werden, um beispielsweise Berechnungen durchzuf¨uhren. So gesehen handelt es sich um eine “eingebaute Skriptsprache”. Viele Systeme bieten solche Skriptsprachen an, um dynamische Seiten zu beschreiben. Wir jedoch schlagen den durchg¨angigen Gebrauch einer funktionalen Sprache vor, die damit gleichzeitig Spezifikations- und Skriptsprache ist. Dies erlaubt eine gr¨oßere Konsistenz der Spezifikation.

4.4

Query- und Updatefunktionen

Die Instanzdaten werden in einer Graphstruktur gespeichert. Ein Knoten des Graphen repr¨asentiert jeweils ein Inhaltsobjekt, die Kanten repr¨asentieren die Beziehungsinstanzen. Der Graph ist eine Instanz des Content-Schemas. Das Wiederfinden von Informationen in Graphen l¨asst sich mit Querying komfortabel realisieren. Graphanfragesprachen sind in der Regel sehr ausdrucksm¨achtig. Uns gen¨ugt eine kleine Menge von Funktionen, um die notwendigen Queries zu formulieren. ¨ Anderungen am Datenbestand, die erforderlichen Updates, geschehen analog mit Funktionen, die den Graphen ver¨andern.

4.5

Pr¨asentationsfunktionen

Die Transformation der abstrakten Seitenbeschreibungen in das gew¨unschte Ausgabeformat wird von Pr¨asentationsfunktionen u¨ bernommen. Diese bestimmen damit das “Aussehen” der Website. In der Regel ist die Zielsprache XHTML, was durch den Ansatz jedoch in keiner Weise vorgeschrieben wird. Abbildung 2 zeigt das Ergebnis einer sehr einfachen Umwandlung der APD f¨ur ein Eingabeformular in XHTML. Die Pr¨asentationsfunktionen sind jederzeit austauschbar, und die Ausgabe kann sogar abh¨angig vom aktuellen Systemzustand variiert werden. Auf diese Weise k¨onnen beliebig viele Ausgabemedien ber¨ucksichtigt werden, und auch die benutzerspezifische Adaption der Seiten (Personalisierung) kann hiermit realisiert werden.

96

4.6

Functional Web Site Specification

Dynamik

Die Gesch¨aftslogik oder Dynamik hinter einer Website wird in den Anforderungsdokumenten erfasst. Es werden zum Beispiel Anwendungsf¨alle oder Szenarios beschrieben, die das erwartete Verhalten der Website festlegen. Anhand der Terminologie, die durch das Content-Modell festgelegt ist, k¨onnen viele Aussagen u¨ ber das Verhalten formalisiert werden. Wir schlagen vor, dies mit funktionalen Spezifikationen zu tun. Als einfaches Beispiel diene die Anforderung im Rahmen des TAS, dass die Eingaben des Benutzers zur Suche nach einer Reise zwei Plausibilit¨atsregeln gen¨ugen m¨ussen: (a) Startund Zielflughafen d¨urfen nicht identisch sein; und (b) Das Abreisedatum liegt sp¨ater als das R¨uckreisedatum. Die folgende Funktion beschreibt genau diese Kriterien: checkWellformedness :: TripDescriptionRecord → Bool checkWellformedness td = (originCity td = destinationCity td) && ( if (isJust (dateOfReturn td)) −− Wurde das Ruckreisedatum angegeben? ¨ then (fromJust (dateOfReturn td) > (dateOfDeparture td)) else True)

(1) (2)

Regel (a) wird in Zeile (1) gepr¨uft, und Zeile (2) l¨asst die Funktion genau dann True zur¨uckliefern, wenn Regel (b) ebenfalls erf¨ullt ist.

5

Stand der Forschung

Modell-basierte Ans¨atze f¨ur die Spezifikation von Websites haben eine lange Tradition. Sie k¨onnen grob anhand ihrer Wurzeln klassifiziert werden: Einige verwenden objektorientierte Modelle, andere Entity-Relationship-Modelle, andere sind eher Dokumentenzentriert. Die einflussreichsten “Schulen” sind der graphbasierte Strudel-Ansatz [FFLS00], das TSIMMIS-Projekt [CGMH+ 94], die ER-basierte RMM [ISB95], Araneus [MMA99], OOHDM [SR95], WebML [Cer00], und UWE. Die Integration von Modellen in eine Programmiersprache anhand einer Dom¨anen-spezifischen Sprache (domain specific language) wird in [NS06] beschrieben. Keiner der uns bekannten Ans¨atze beruht in dem hier vorgeschlagenen Maße auf funktionalen Spezifikationen. Die Erzeugung von HTML und XML mit funktionalen Programmiersprachen kann mit komfortablen Bibliotheken erfolgen (z.B. [Thi02]), die zus¨atzlich die syntaktische Korrektheit der erzeugten Dokumente garantieren. Durch das m¨achtige Typsystem von Haskell gelingt es sogar, die (Pseudo-)Validit¨at eines HTML-Dokuments zur Compilezeit u¨ berpr¨ufen zu lassen. Es werden auch vollst¨andige Webserver in funktionalen Sprachen implementiert (insbesondere [Thi07], [Han06]). Diese Systeme erlauben es, Webanwendungen zu programmieren, ohne sich um komplexe Fragen des konsistenten Session-Handlings k¨ummern zu m¨ussen (z.B. was geschieht, wenn der Benutzer die

Torsten Gipp

97

“Zur¨uck”-Taste des Browsers benutzt und ein Formular ein zweites Mal absendet). Die genannten Ans¨atze ber¨ucksichtigen aber nicht den Modellierungsaspekt, sondern fokussieren auf die Implementierungsebene.

6

Zusammenfasssung und Ausblick

Der hier vorgestellte Ansatz verwendet funktionale Spezifikationen zur Modellierung von Websites. Wir folgen einer strikten Trennung der Belange und identifizieren sechs Kernbereiche, die getrennt voneinander betrachtet und modelliert werden k¨onnen. Die Bereiche sind der Content, die Navigation, die Seiten, die Queries und Updates, die Pr¨asentation und die Dynamik. Das Content-Modell und die Navigationsstruktur sind durch ‘herk¨ommliche’ Modelle erfasst, n¨amlich einem objekt-orientierten, konzeptuellen Modell respektive einer visuellen Sprache. Die anderen vier Aspekte werden formal, mit Hilfe einer funktionalen Sprache, notiert. Wir verwenden die funktionale Programmiersprache Haskell. Durch die funktionale Sprache werden die Spezifikationen konzis, leichter wartbar und wiederverwendbar. Jederzeit k¨onnen neue Abstraktionsebenen definiert werden, was die Modellierung erheblich vereinfacht. Der wichtigste Punkt ist jedoch, dass die Spezifikationen direkt ausf¨uhrbar sind. Unser Ansatz soll weiterentwickelt werden. Die Speicherung des Content im Graphen erfolgt derzeit noch ohne die Ber¨ucksichtigung von Typinformationen. Die durchg¨angigere Verwendung von Typinformationen w¨urde die Spezifikation noch weiter verbessern. Die Integration unseres Ansatzes in einen funktionalen Webserver, wie bereits in Abschnitt 5 erw¨ahnt, w¨urde neue M¨oglichkeiten der dynamisierten Ausgabesteuerung er¨offnen. Nicht zuletzt sollte der Ansatz um eine komfortablere Benutzungsschnittstelle erweitert werden. Das Verfassen der funktionalen Spezifikation in einem Texteditor entspricht nicht dem, was einem nicht versierten Benutzer zugemutet werden kann. Hier k¨onnte eine visuelle Sprache, mit entsprechender Werkzeugunterst¨utzung, einen großen Fortschritt bringen. Das Werkzeug w¨urde dann beispielsweise die Seitenfunktionen als Ausgabe liefern, und sie k¨onnten direkt ausgef¨uhrt werden. Hier m¨ochten wir bestehende Modellierungsans¨atze auf geeignete Modellierungssprachen untersuchen, um eine Integration dieser Ans¨atze mit dem unseren zu vollziehen.

Literatur [Cer00]

Stefano Ceri. Web Modeling Language (WebML): a modeling language for designing Web sites. Computer Networks (Amsterdam, Netherlands: 1999), 33(1–6):137–157, 2000.

[CGMH+ 94] Sudarshan Chawathe, Hector Garcia-Molina, Joachim Hammer, Kelly Ireland, Yannis Papakonstantinou, Jeffrey D. Ullman und Jennifer Widom. The TSIMMIS Project: Integration of heterogeneous information sources. In 16th Meeting of the Information Processing Society of Japan, Seiten 7–18, Tokyo, Japan, 1994.

98

Functional Web Site Specification

[FFLS00]

Mary Fern´andez, Daniela Florescu, Alon Y. Levy und Dan Suciu. Declarative Specification of Web Sites with Strudel. VLDB Journal, 9(1):38–55, 2000.

[GE07]

Torsten Gipp und J¨urgen Ebert. Functional Web Applications. In Piero Fraternali, Luciano Baresi und Geert-Jan Houben, Hrsg., 7th International Conference on Web Engineering (ICWE 2007), LNCS (to appear). Springer-Verlag, 2007.

[Gip06]

Torsten Gipp. Functional Web Site Specification. Logos Verlag Berlin, Berlin, 2006.

[Han06]

Michael Hanus. Type-Oriented Construction of Web User Interfaces. In Proc. of the 8th International ACM SIGPLAN Conference on Principle and Practice of Declarative Programming (PPDP’06), Seiten 27–38. ACM Press, 2006.

[ISB95]

Tom´as Isakowitz, Edward A. Stohr und P. Balasubramanian. RMM: A Methodology for Structured Hypermedia Design. Communications of the ACM, 38(8):34–44, 1995.

[KPRR04]

Gerti Kappel, Birgit Pr¨oll, Siegfried Reich und Werner Retschitzegger, Hrsg. Web Engineering: Systematische Entwicklung von Web-Anwendungen. dpunkt.verlag, Heidelberg, 2004.

[MMA99]

Giansalvatore Mecca, Paolo Merialdo und Paolo Atzeni. Araneus in the Era of XML. IEEE Data Engineering Bulletin, 22(3):19–26, September 1999.

[NS06]

Demetrius A. Nunes und Daniel Schwabe. Rapid prototyping of web applications combining domain specific languages and model driven design. In ICWE ’06: Proceedings of the 6th international conference on Web engineering, Seiten 153–160, New York, NY, USA, 2006. ACM Press.

[SR95]

Daniel Schwabe und Gustavo Rossi. The Object-Oriented Hypermedia Design Model. Communications of the ACM, 38(8):45–46, 1995.

[Thi02]

Peter Thiemann. A Typed Representation for HTML and XML Documents in Haskell. Journal of Functional Programming, 12(4 and 5):435–468, July 2002.

[Thi05]

Peter Thiemann. An Embedded Domain-Specific Language for Type-Safe ServerSide Web-Scripting. ACM Transactions on Internet Technology, 5(1):1–46, 2005.

[Thi07]

Peter Thiemann. Web Authoring System Haskell (WASH). http://www.informatik. uni-freiburg.de/∼thiemann/haskell/WASH/, February 2007.

Dr. Torsten Gipp wurde am 27.12.1975 in Boppard am Rhein geboren. Nach der Erlangung der Allgemeinen Hochschulreife in 1995 begann er mit dem Studium der Informatik an der Universit¨at Koblenz-Landau, das er im Jahre 2000 mit dem Diplom erfolgreich beendete. Im Anschluss arbeitete er als wissenschaftlicher Mitarbeiter am Institut f¨ur Softwaretechnik der Universit¨at Koblenz-Landau und promovierte im Jahr 2006 zum Dr. rer. nat. In den Jahren zwischen 1995 bis 2002 arbeitete Herr Gipp als Softwareentwickler in einem Softwarehaus. Seit 2005 ist er an der Universit¨at Koblenz-Landau mit der Universit¨ats-weiten Einf¨uhrung eines ContentManagement-Systems beauftragt. In seiner Freizeit f¨ahrt Herr Gipp mit dem Mountain-Bike, joggt, er kocht gerne und tanzt Salsa. Seit etwa einem Jahr besch¨aftigt er sich zudem mit der spanischen Sprache.