08.12.2012 Aufrufe

2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...

2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...

2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

Abbildung 49: Vereinfachtes Inhaltsmodell zur Implementierung<br />

mit Rails (Ausschnitt)<br />

Die Idee, aufgrund der gerade beschriebenen Schwierigkeiten vollständig auf eine<br />

Vererbungshierarchie zu verzichten, und stattdessen die Publication-Klasse mit einem<br />

zusätzlichen Typ-Attribut zur Spezifikation des jeweiligen BibTeX-Literaturtyps zu versehen,<br />

wurde allerdings verworfen. Denn im Gegensatz zu strukturellen Merkmalen konnten<br />

Verhaltensmerkmale wie gewohnt je nach Bedarf in den verschiedenen Subklassen definiert<br />

bzw. überschrieben werden. Insbesondere galt dies für die unterschiedlichen<br />

Validierungsmechanismen der einzelnen Subklassen. Hier bietet Rails umfangreiche<br />

Unterstützung an: Jedes Modellobjekt (d.h. jedes Objekt einer Klasse, die von<br />

ActiveRecord::Base erbt) besitzt defaultmäßig ein Error-Objekt, welches zur<br />

Speicherung der Validierungsfehler bzgl. einzelner Attributwerte dient. Zusätzlich stellt das<br />

ActiveRecord-Modul zahlreiche Hilfsmethoden zur Verfügung, um Modellklassen mit<br />

standardmäßiger Validierungsfunktionalität auszustatten.<br />

7.3.2 Umsetzung des Navigations- und Prozessmodells<br />

Während es für das <strong>UWE</strong>-Inhaltsmodell und, wie später noch gezeigt wird, auch das <strong>UWE</strong>-<br />

Präsentationsmodell mit der Modell- und der View-Komponente einer Rails-Anwendung<br />

jeweils Programmkompontenten gibt, die eine relativ hohe Strukturgleichheit mit dem<br />

jeweiligen <strong>UWE</strong>-Modell aufweisen, gilt dies für das Navigationsmodell nur in sehr<br />

eingeschränktem Maße. Bei der Realisierung dieses Modells fielen zwei Dinge ins Auge:<br />

Erstens gibt es keine Stelle in einer Rails-Anwendung, in der die Navigationsstruktur des<br />

Systems so umfassend und kompakt festgelegt wird wie im <strong>UWE</strong>-Navigationsmodell.<br />

Zweitens gibt es in Ruby on Rails keine Entsprechung für das Konzept des<br />

Navigationsknotens als abstrakte Repräsentation eines ansteuerbaren Punktes im<br />

Navigationsnetz. Rails kennt nur konkrete Realisierungen solcher Navigationspunkte in Form<br />

von dynamischen <strong>Web</strong>seiten (ERb-Templates), die ihre Entsprechung auf <strong>UWE</strong>-Ebene in<br />

Präsentationsgruppen des Präsentationsmodells finden.<br />

Es ist allerdings klar, dass wesentliche Informationen, die im Navigationsmodell codiert sind,<br />

in der Rails-Controller-Schicht umgesetzt werden müssen. Controller-Actions sind für die<br />

Verarbeitung von HTTP-Requests zuständig, sie legen fest, welche Navigationseinheit - oder<br />

konkret, welche dynamische <strong>Web</strong>seite - , als Antwort auf eine Anfrage angesteuert bzw.<br />

gerendert werden soll, und sie bestimmen die Datengrundlage dieser <strong>Web</strong>seite. Diese<br />

Informationen finden sich bei <strong>UWE</strong> im Navigationsmodell. In einer ersten Vereinfachung<br />

können Links zwischen Navigationsklassen als HTTP-Anfragen aufgefasst werden, deren<br />

Zielknoten abstrakte Repräsentationen der <strong>Web</strong>seiten darstellen, die als Antwort auf den<br />

82

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!