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

7.3 Umsetzung der UWE-Modelle
7.3.1 Umsetzung des Inhaltsmodells
Es ist klar, dass die Klassen des UWE-Inhaltsmodells in der Modell-Komponente von Rails
umzusetzen waren. Aufgrund der Objektorientierung von Ruby ist die Implementierung
prinzipiell sehr geradlinig – die Elemente des Inhaltsmodells (Klassen, Attribute, Methoden,
Assoziationen) müssen 'einfach' in die entsprechenden programmiersprachlichen Konstrukte
von Ruby übersetzt werden. Allerdings war zu berücksichtigen, dass die Domänenobjekte der
Modellklassen (Publikationen, Personen etc.) in geeigneter Weise in einer relationalen
Datenbank persistiert werden müssen. Zur Lösung dieser Aufgabe stellt Ruby on Rails mit
dem ActiveRecord-Modul einen objektrelationalen Mapper zur Verfügung. Allerdings bringt
dessen Einsatz eine Einschränkung mit sich, die sich bei der Umsetzung des UWE-
Inhaltsmodells bemerkbar gemacht hat. Sie soll im Folgenden erläutert werden.
Während objektorientierte Sprachen Daten in Objekten kapseln, basieren relationale
Datenbanken auf dem mathematischen Konzept der Relation, um Daten in Form von Tabellen
zu verwalten. Die Technik der objektrelationalen Abbildung dient zur Überbrückung der
strukturellen Unterschiede, die sich aus der Verwendung dieser beiden Paradigmen ergeben.
Ruby on Rails integriert mit ActiveRecord einen objektrelationalen Mapper, der das
gleichnamige Design-Pattern von Martin Fowler realisiert: Die strukturellen Aspekte einer
Domänen-Klasse werden 1:1 auf eine Datenbanktabelle abgebildet, für jedes Attribut existiert
eine entsprechende Tabellenspalte, ein Datensatz einer Tabellenzeile entspricht damit genau
einem Objekt. Zusätzlich enthält die Klasse Domänenlogik und Methoden zum Zugriff auf die
Datenbank 67 .
Zur Abbildung von Vererbungshierarchien auf Datenbankebene greift Rails auf ein weiteres
Design Pattern von Fowler zurück: Mit Single Table Inheritance (SIT) werden alle Klassen
der Hierarchie auf eine Tabelle abgebildet. Diese Tabelle besitzt für jedes Attribut jeder
Klasse der Vererbungshierarchie eine entsprechende Spalte. In einer zusätzlichen Kolumne
wird der Typ des Objekts gespeichert, um bei der Rematerialisierung dem aus der Datenbank
zu ladenden Objekts den richtigen Typ zuweisen zu können. Diese Methode zur Erfassung
von Vererbungshierarchien in relationalen Datenbanken hat einige Vorteile, z.B. sind im
Vergleich zu Techniken, die den Einsatz mehrerer Tabellen erfordern, keine kostspieligen
Join-Operationen notwendig. Auf der Soll-Seite ist dagegen unnötiger Speicherplatzverbrauch
und unübersichtliches Tabellendesign zu verbuchen: Viele, wenn nicht gar alle Datensätze der
Tabelle besitzen ungenutzte Felder, die zu ihrer Beschreibung nicht benötigt werden, da die
entsprechenden Spalten zur Abbildung von Attributen anderer Subklassen dienen.
Problematisch ist nun, dass im ActiveRecord-Modul von Rails ein derart hohes Maß an
Strukturgleichheit von Objekt- und Datenbankebene realisiert wird, dass diese zuletzt
genannte Schwäche von SIT sogar auf Objektebene übertragen wird: Die Koppelung von
Objekt- und Datenbankebene ist hier so stark, dass nicht nur alle Datensätze der
Vererbungstabelle alle Felder besitzen, sondern dass sich auch alle Domänenklassen der
Vererbungshierarchie die Attribute aller Subklassen teilen 68 . Neben einem unsauberen
Tabellen- erhält man zwangsläufig auch ein unsauberes Modelldesign: Objekte besitzen
Attribute, die sie eigentlich nicht haben sollten, und der Programmierer muss selbst dafür
Sorge tragen, dass bei den Instanzen einer betroffenen Modellklasse keine sinnlosen Attribute
67 [9], S.160ff
68 Siehe dazu auch [36], S.261
80