2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...
2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...
2 UML-based Web Engineering - UWE - Ludwig-Maximilians ...
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