Objektorientiertes Design eines Gästebuchs

1. Einleitung

Objektorientiertes Design eines Gästebuchs

"Ich hab da was programmiert, aber es funktioniert so nicht. Kann mir einer helfen?". Auf diese, nicht zu selten in PHP-Foren auftauchende, Art der Frage passt zu einem sehr hohen Prozentsatz die Antwort: "Think before you start to write code!". Die Bedeutung von Softwaredesign wird in der PHP-Community meiner Einschätzung nach leider immer noch zu wenig beachtet. Die Einstiegshürde ist gegenüber der JAVA-Entwicklung niedrig und doch scheuen viele Entwickler den Aufwand, Zeit für die Analyse der Aufgabenstellung und das Design der Software zu investieren, weil die Zeit bereits für die produktive Entwicklung eingesetzt werden kann.

Diese Annahme ist jedoch ein Trugschluss, denn sofort mit der Implementierung zu beginnen bedeutet Fehler an der Umsetzungsidee erst während der Entwicklung zu finden. Das hat mehrfaches Refactoring und aufwendige Fehlerbehebung zur Folge. Und: je später ein Fehler im Software-Lifecycle gefunden wird, desto teurer ist er!

Hinzu kommt, dass Anwendungen, die ohne Design - und damit ohne klares Ziel - erstellt wurden, oft nicht für zukünftige Weiterentwicklung ausgelegt sind. Änderungen und Erweiterungen werden teuer. Kommen neue Mitarbeiter zum Projekt, haben diese oft kaum eine Chance, sich in bestehende Systeme einzuarbeiten, da die Dokumentation fehlt.

In Summe betrachtet, sind die Umsetzungskosten von Projekten mit gutem Softwaredesign daher sogar niedriger!


2. Warum Objektorientierung?

Hinter objektorientiertem Design (OOD) und objektorientierter Implementierung (OOP) steckt die Idee, in Realität existierende Problemstellungen in Objekte und deren Beziehungen abzubilden. Die Prozess-Logik wird dabei über die Methoden der Objekte definiert.

Durch starke Segmentierung der Elemente und Prozesse einer Software erhofft sich der Entwickler übersichtliche, leicht implementierbare Funktions-Einheiten. Weiterhin hilft eine große Sammlung an Design-Pattern (siehe Übersicht Design-Pattern), die Aufgabenstellungen mit erprobten Standard-Lösungen zu belegen.

Der Nachteil dieser Vorgehensweise scheint zunächst der Overhead an Dokumentation und Code zu sein, der sich jedoch mit dem Betrieb und der Erweiterung der Applikation als nützlich herausstellt. Module sind bei einem guten Design klar strukturiert, Funktionen zentral bereitgestellt und Erweiterungen lassen sich mit wenig Aufwand einbringen.


3. Design Pattern

Ein Design Pattern beschreibt eine Lösung für ein wiederkehrendes Problem. Dabei wird sowohl auf die Aufgabenstellung und Umsetzung, als auch auf die Rahmenbedingungen, in der es eingesetzt werden kann, eingegangen. Durch die Verwendung von erprobten Ansätzen kann unter Architekten und Entwicklern eine gemeinsame Sprachregelung etabliert werden. Dies erleichtert nicht nur die Einarbeitung in ein neues Aufgabengebiet, sondern erhöht auch die Lesbarkeit und die Struktur der Software. Aus diesem Grund soll beim Design der Gästebuch-Anwendung nach Möglichkeit auf anerkannte Design-Pattern zurückgegriffen werden.

Bei deren Einsatz ist jedoch zu beachten, dass sich ein gutes Software-Design nicht an der Anzahl der eingesetzten Entwurfsmuster, sondern an der Qualität der Lösung, misst. Eine unangemessen hohe Anzahl von Pattern scheitert vor allem dann, wenn die Einsatzgebiete und Rahmenbedingungen derselben nicht beachtet wurden.

Beim Design einer Software-Lösung darf der Einsatz von Design Pattern aber auch nicht überbewertet werden. Nicht für jede Aufgabenstellung ist bereits ein geeignetes Pattern vorhanden. Die Kunst eines Software-Designers besteht also darin, verschiedene Lösungsmodelle so zu kombinieren, dass diese einen maximalen Nutzen für das Applikationsdesign bedeuten. Dabei kann es auch notwendig sein, verschiedene Pattern in einer Weise zu kombinieren, dass die Nachteile des einen durch die Vorteile des anderen aufgewogen werden. Dieses Vorgehen wird auch als "cooperation of design patterns" bezeichnet.


4. Grundlagen

Um in den folgenden Abschnitten von gleichen Kenntnissen ausgehen zu können, zunächst ein paar Worte zu zentralen Design Pattern und best practices für objektorientiertes Softwaredesign.

Die Kapselung von Funktionalität in eigenständige Komponenten ist eine, in der objektorientierten Welt, sehr verbreitete Methodik. Dabei geht der Entwickler beim Erstellen des Designs der Software davon aus, dass unterschiedliche Schichten der Software (siehe Mehrschicht-Architektur) jeweils typische Aufgaben übernehmen. Dies ermöglicht nicht nur eine bessere Widerverwendbarkeit der erstellten Services (Komponenten), sondern vereinfacht auch die Einbindung von mehreren Entwicklern oder Teams.

Im Enterprise-Bereich hat sich die three tier architecture etabliert. Diese sieht vor, dass Anwendungen in eine Präsentationsschicht, ein oder mehrere Business-Komponenten und eine Daten-Schicht unterteilt sind. Die Präsentations-Schicht übernimmt die Darstellung. Sie nutzt die Business-Schicht zur Beschaffung von Daten und Informationen zu Art und Inhalt der Darstellung. Die Business-Schicht repräsentiert die Anwendungslogik und bildet die Geschäftsprozesse ab. Die Datenschicht beschäftigt sich mit der Beschaffung und Speicherung von Daten.

Innerhalb der genannten Schichten existieren weitere Pattern zur Verfeinerung der Vorgehensweisen:

Im Bereich der Datenschicht wird häufig das DataMapper-Pattern zitiert. Dieses fungiert als Vermittler zwischen der Welt der Datenbank und der Welt der Anwendung. Das bedeutet, dass sich diese Komponente mit den Spezifika der Datenbank beschäftigt und der Software eine einfache Schnittstelle bietet um Daten in Form von (Domänen-) Objekten zu lesen oder zu speichern. Zur weiteren Strukturierung der Business-Schicht können das Domain-Object- und Front-Controller-Pattern eingesetzt werden:

Das Domain-Model einer Anwendung beschreibt dabei die verarbeiteten Daten und den internen Ablauf. In einfachen Anwendungen, wie beispielsweise dem Gästebuch, wird es meist nur genutzt um die vorhandenen Datentypen (Benutzer, Eintrag, ...) zu beschreiben.

Der Front-Controller ist vor allem in Web-Applikationen von großer Bedeutung, da er die Möglichkeit bietet, die Business-Schicht-Komponenten vor der Generierung des Benutzer-Interfaces zu initialisieren. Daraus leitet sich die Möglichkeit ab, die Elemente der grafischen Oberfläche durch Model-Parameter direkt zu steuern. Generische Implementierungen des Patterns ermöglichen zudem, allgemeine Aufgaben wie URL-Parameter-Filterung direkt nach der Entgegennahme des Requests zu platzieren. So kann beispielsweise die Sicherheit der Applikation bereits an einem zentralen Punkt sichergestellt werden.

Für die nähere Beschreibung der Präsentationsschicht bieten sich das Model-View-Controller (MVC)- und das Page-Controller-Pattern an.

Das MVC-Pattern beschreibt die Trennung zwischen dem dargestellten Inhalt und der Definition der Applikations-Workflows (Model), der Beschreibung der Darstellung und des Aussehens der Applikation (View) und der eigentlichen Darstellungs-Logik (Controller). Auch hier soll die Trennung in weitere Schichten für mehr Flexibilität bei Erweiterungen und Vereinfachung der Wartung sorgen. Um bei der Erstellung einer Applikation noch mehr Flexibilität bei der Strukturierung der Views zu haben, sieht das hierarchische MVC (HMVC)-Pattern eine Präsentations-Schicht aus einem hierarchischen Baum von kleinen MVC-Einheiten vor. Dabei wird das Model eines Moduls oder einer Applikation nicht direkt an eine solche gebunden, sondern steht mehreren zur Verfügung.

Die Funktion des Page-Controller besteht darin, die Anfragen an eine Applikation an einer zentralen Stelle entgegen zu nehmen, diesen zu interpretieren und die gewünschten Module einer Applikation auszuführen. Dabei bietet er insbesondere einen allgemeingültigen Rahmen für nach dem MVC-Pattern implementierte Applikationen.

Auch wenn der Page-Controller nur selten in Artikeln mit MVC in Verbindung gebracht wird, ist der isolierte Einsatz von MVC nur in sehr einfachen Anwendungsfällen wertvoll. In größeren oder komplexeren Projekten führt die immer wiederkehrende Implementierung der MVC-Mechanismen zu einem starken Mehraufwand, was den Einsatz des Patterns nicht mehr rechtfertigen würde.

Neben den genannten Entwurfsmustern existiert noch eine Vielzahl Weiterer. Unter [5] im Info-Kasten findet sich Link zu einer Übersicht über vorhandene Design-Pattern.


5. Requirements

Für die Analyse der Anforderungen und das Erstellen des Software-Designs, sollten die Anforderungen weitestgehend klar sein. Die reine Lehre der agilen Software-Entwicklung geht davon aus, dass auch die Anforderungen agil sind, die Erfahrung zeigt jedoch, dass diese zu einem großen Teil stabil sein sollten. Aus diesem Grund schickt es sich, offene Fragen im Rahmen eines Design-Reviews zusammen mit dem Kunden vor dem Beginn der Implementierung zu klären.

Die folgende Liste beinhaltet die Anforderungen an das zu erstellende Gästebuch:
  • Das Gästebuch soll in mehreren Sprachen gleichzeitig einsetzbar sein.
  • Das Layout soll per CSS frei formatierbar sein (z.B. Ausgabe der Einträge, Formular-Elemente, ...).
  • Das Gästebuch soll als Modul in mehreren Webseiten ohne Code-Änderungen einsetzbar sein.
  • Die festen sprachabhängigen Texte sollen in einer Konfigurationsdatei pflegbar sein.
  • Das Gästebuch soll schnell auf Benutzer-Eingaben reagieren.
  • Ein Eintrag besteht aus Titel, Text und Erstellungsdatum. Weiterhin sollen die Attribute Name, E-Mail und Webseite vom Besucher abgefragt werden.
  • Die Einträge sollen in einer blätterbaren Liste mit dynamischer Anzahl von Einträgen pro Seite dargestellt werden.
  • Der Titel und die Beschreibung des Gästebuchs sollen pro Sprache pflegbar sein.
  • Bereits erstellte Beiträge sollen nach einem Login editierbar sein um die Administration zu erleichtern.
Die Formulierung der genannten Punkte lässt erkennen, dass es sich hierbei lediglich um funktionale Anforderungen (z.B. Mehrsprachigkeit, Paging) bzw. Umgebungs-Anforderungen (z.B. Performance, Styling) handelt. Bei komplexen Applikationen ist es ebenso wichtig, auch die nicht-funktionalen Anforderungen zu definieren. Diese können in Form von Screen-Designs, die das statische Aussehen einer Applikation beschreiben, dokumentiert werden. Erfahrungsgemäß ergeben sich aus den Kundengesprächen oft noch weitere funktionale Anforderungen, die so bisher noch nicht geäußert wurden!

Die nicht-funktionalen Anforderungen sollen jedoch in diesem Artikel ausgeklammert werden, da das Gästebuch ohnehin per CSS frei formatierbar sein soll. Damit steht jedem Anwender ein probates Mittel zur Gestaltung zur Verfügung.

Die folgenden Abschnitte widmen sich nun der Analyse der Anforderungen und der Erstellung der Design-Dokumentation des Gästebuchs. Zur Problem-Analyse und Dokumentation der erarbeitetet Lösung wird die Beschreibungs- und Modellierungssprache UML eingesetzt.


6. Use Cases

Für die genauere Betrachtung von komplexen Software-Systemen bietet sich die Erstellung einer Robustness-Analyse an. Die daraus resultierenden Grafiken beinhalten alle Aktoren, Schnittstellen und Services und ermöglichen einem ersten Überblick über die zu erstellende Lösung zu erhalten.

Da die Anforderungen des Gästebuchs jedoch in einem überschaubaren Rahmen liegen, kann die Analyse mit der Erstellung von Use Cases vorgenommen werden. Use Case-Diagramme bieten dafür eine recht einfache Möglichkeit, alle dem Benutzer zur Verfügung stehenden Elemente strukturiert zu dokumentieren. Die erstellten Grafiken enthalten dabei Aktoren, Anwendungsfälle und deren Beziehungen.

Sofern die Anforderungen des Kunden unstrukturiert vorliegen, können Use Cases auch für eine grobe Analyse der Anforderungen zusammen mit dem Kunden eingesetzt werden.

Da es sich bei UML um eine formale, grafische Beschreibungssprache handelt, sollten die erstellten Diagramme möglichst selbsterklärend sein. Bei komplexeren Projekten sollte eine textuelle Beschreibung jedoch nicht fehlen. Üblicherweise werden zur Detaillierung Use Case-Templates eingesetzt, die einen Use Case mit weiteren Informationen wie Vorbedingung, Standard- und Fehler-Verhalten ausstatten. Ein Vorschlag hierfür findet sich in der Linkliste am Ende des Artikels.

Die folgende Abbildung strukturiert die Anwendungsfälle, die in den Anforderungen des Gästebuchs beschrieben sind:

Im Diagramm sind zwei Aktoren abgebildet. Diese beschreiben die beiden in der Applikation auftretenden Rollen. Der Besucher ("Visitor") initiiert das Anzeigen des Gästebuchs und agiert als Autor für neue Einträge. Der Administrator ("Editor") kontrolliert die Inhalte und korrigiert diese gegebenenfalls.

Das Verfassen eines Eintrags ist mit dem Anzeigen des Formulars und dessen Speicherung verbunden. Um der Anforderung gerecht zu werden, Einträge in einer paginierbaren Liste anzuzeigen, müssen beim Betrachten des Gästebuchs sowohl die Seiteninformation als auch die für die Seite relevanten Einträge selbst dargestellt werden.

Das Editieren eines Beitrags umfasst mehrere Aktivitäten, die im Diagramm mit include- und dependency-Beziehungen gekennzeichnet sind. Include-Beziehungen werden verwendet, wenn ein Use Case einen anderen beinhaltet. Kann ein solcher nur ausgeführt werden, wenn ein anderer erfüllt ist, wird dies durch eine dependency-Beziehung gekennzeichnet.

Nachdem sich der Redakteur authentifiziert hat, kann dieser den gewünschten Beitrag auswählen, diesen zur Bearbeitung anzeigen lassen und anschließend abspeichern.

Das Erstellen von Use Case Diagrammen scheint zunächst eine triviale Aufgabe zu sein. Sie ist jedoch von nicht geringer Bedeutung, da sich daraus die Views, die dem Nutzer auf GUI-Ebene zur Verfügung gestellt werden, zumeist direkt ergeben.


7. Daten-Modellierung

Nach der Analyse der Anwendungsfälle widmen wir uns den im Gästebuch verarbeiteten Daten. Hierfür ist es von Vorteil, zunächst die Objekte der Anwendung (=Domäne) unabhängig von Datenhaltung und Darstellung zu betrachten. In einem weiteren Schritt kann dann auf den Ergebnissen des Domänen-Modells die Modellierung der Datenschicht vorgenommen werden.

Wie bereits in einem der voran gegangenen Abschnitte angesprochen, bedeutet Objektorientierung die Abbildung einer reellen Problemstellung in Objekten, deren Funktionen und Beziehungen. Wer versucht ist, bereits zum Zeitpunkt der Daten-Analyse Besonderheiten der Darstellung oder Speicherung mit in die Modellierung einzubeziehen, läuft Gefahr, sich von der Realität zu entfernen.

Für eine korrekte Datenmodellierung sollten folgende Grundregeln und best practices beachtet werden:
  • Objekte sollten genau mit einer Aufgabe betraut sein.
  • Sofern ein Attribut eines Objektes mehrfach verwendet wird, sollte dieses als eigenes Objekt ausgelagert und mit einer Beziehung referenziert werden.
  • Die Komposition bezeichnet eine starke Zugehörigkeit (Beispiel: Gästebuch hat Einträge).
  • Jedes Objekt darf nur einmal komponiert werden, da ein reelles Objekt nur exakt eine starke Zugehörigkeit besitzen kann.
  • Die Assoziation bezeichnet eine schwache Zugehörigkeit. Diese wird verwendet, um für eine Applikation logisch zusammen gehörende Objekte zu verbinden. Assoziationen können jederzeit aufgelöst werden, da das betroffene Objekt weiterhin "lebt".
In den folgenden Abschnitten wird zwischen dem Daten-Modell der Anwendung (domain object model) und dem Daten-Modell der Datenschicht (data layer object model) unterschieden.


8. Domänen-Modell

Das domain object model (siehe Informationen zum domain object pattern) beschreibt die Objekte, die in einer Anwendung direkt verarbeitet werden. Dabei wird sowohl auf die Ausprägung der Objekte als auch die Beziehungen zu Anderen eingegangen.

Das folgende Diagram zeigt die für ein Gästebuch relevanten Objekte:

Das Guestbook-Objekt repräsentiert die Instanz eines Gästebuchs. Es beinhaltet den Titel und die Beschreibung des Gästebuchs. Über die Assoziation Guestbook2Administrator ist diesem ein Benutzer (Typ: User) als administrativer Account zugeordnet. Die Beziehung wird dabei vom Objekt Guestbook initiiert, da zur Verwaltung des Gästebuchs ein Administrator vorhanden sein muss.

Das Objekt Entry beschreibt die Daten, die in einem Gästebuch-Eintrag abgespeichert werden. Die Attribute des Verfassers werden über die Assoziation Editor2Entry mit dem Eintrag verknüpft. Die Beziehung wird in diesem Fall vom User initiiert, da die Erstellung des Eintrags von diesem ausgeht und nicht umgekehrt.

Weiterhin besitzt das Objekt Entry eine Beziehung vom Typ Komposition zum Objekt Guestbook. Diese lässt erkennen, dass das Gästebuch mehrere Einträge besitzt. Die Qualität der Beziehung beschreibt zudem, dass ein Entry-Objekt nicht ohne ein Guestbook existieren kann.


9. Mehrsprachigkeit

Um der Anforderung nach Mehrsprachigkeit des Gästebuchs gerecht zu werden, ist eine Erweiterung des Domänen-Modells notwendig, da dieses bisher keine Zuordnung eines Gästebuchs oder Eintrags zu einer Sprache "kennt".

Aus diesem Grund soll nun das Daten-Modell der Anwendung von dem der Datenhaltung getrennt werden. Vorteil dieser Verfahrensweise ist, dass die Anwendung nochmals von der Datenhaltung abstrahiert wird und Änderungen zu einem späteren Zeitpunkt dadurch erleichtert werden.

Die Erweiterung besteht nun darin, die Attribute der Domänen-Objekte durch sprachabhängige Attribute-Objekte zu ersetzen. Diese sind den "eigentlichen" Guestbook- oder Entry-Objekt mit einer Komposition zugewiesen, besitzen jedoch gleichzeitig eine Zuordnung (Assoziation) zu einer Sprache. Das zugehörige UML-Diagramm gestaltet sich dann wie folgt:

Die Anforderungen beschreiben, dass ein Gästebuch in mehreren Sprachen einsetzbar sein soll. Dies ist nur dann möglich, wenn es nur eine Instanz gibt, der die sprachabhängigen Attribute direkt zugeordnet sind. Andernfalls kann die Mehrsprachigkeit nur über eigene Gästebücher für jede Sprache abgebildet werden.

Für Einträge ist es hingegen möglich, jeweils ein Entry-Objekt direkt mit den sprachabhängigen Werten zu füllen und zu einer Sprache zuzuordnen. Die Einträge eines Gästebuchs können dann durch Einschränkung über die Beziehung zum Gästebuch und der aktuell gewählten Sprache selektiert werden. Um die Lesbarkeit zu erhöhen und die Erweiterbarkeit des Datenmodells zu vereinfachen, wird auch diesem Fall auf die Auslagerung der Attribute in eigene Objekte gesetzt. Als Nachteil dieser Vorgehensweise ist der erhöhte Aufwand beim Lesen und Schreiben von Daten zu nennen.

Um die Erweiterung des Domänen-Modells um sprachabhängige Attribute-Objekte für die Anwendung selbst transparent zu gestalten wird das Mapping der sprachabhängigen Werte komplett an die Daten-Schicht delegiert. Diese füllt beim Lesen die Guestbook- und Entry-Objekte mit den für die ausgewählte Sprache relevanten Daten und übersetzt beim Speichern die Domänen-Objekte in sprachabhängige Attribute-Objekte.


10. Datenmodell

In großen Datenhaltungskonzepten werden in der Regel mehr Daten abgespeichert, als eine einzelne Anwendung benötigt. Werden in der von der Gästebuch-Applikation benutzen Datenbank neben den Einträgen noch Termine, Orte, Länder und deren Beziehungen gespeichert, so ist es Aufgabe der Datenschicht der Gästebuch-Anwendung nur diejenigen Daten zur Verfügung zu stellen, die auch zur Ausführung benötigt werden.

Im letzten Abschnitt haben wir zudem festgesetzt, dass die Lösung für das Thema Mehrsprachigkeit über ein erweitertes Daten-Modell abgebildet werden soll. Folglich unterscheidet sich auch in diesem Fall das Daten- vom Domänen-Model.

Für die Vermittlung zwischen diesen beiden soll der data mapper verwendet werden. Das Pattern beschreibt die Trennung der Datenhaltungs-Logik von der Applikations-Logik. Damit benötigt ein Domänen-Objekt keine Kenntnisse über die Art der Abbildung auf eine relationale Datenbank. Die Trennung von Aufgaben in unterschiedliche Schichten wird dadurch maßgeblich erleichtert. Abgesehen davon lässt sich der Sinn der Trennung allein darin begründen, dass eine Programmiersprache über andere Mechanismen zur Abbildung von Kompositionen und Assoziationen verfügt als eine relationale Datenbank.

Im Folgenden ist nun das um Mehrsprachigkeit erweitertet Datenmodell auf eine relationale Datenbank beschrieben:

Dem Tabellen-Design liegen folgende Prinzipien zu Grunde:

Die "einfachen" Attribute eines Objekts werden in einer eigenen Tabelle abgelegt. Dies vereinfacht nicht nur die Abfrage der Daten eines Objekts, sondern ist auch aus Sicht der Performance günstiger. Nachträgliche Änderungen und Erweiterungen eines Objekts können immer an zentraler Stelle vorgenommen werden.

Beziehungen - "komplexe" Attribute - werden ebenso in eigenen Tabellen abgebildet. Dies erzeugt beim Abfragen von Beziehungsobjekten zunächst einen größeren Umfang der Statements, ermöglicht jedoch die Abbildung von n:m-Beziehungen. Ein weiterer Vorteil ist die Wartung des Datenmodells. Wird bei der Weiterentwicklung ein zusätzliches Objekt mit mehreren Beziehungen hinzugefügt, kann dieses sehr einfach in die bestehende Struktur eingegliedert werden.

Der hier verwendete Abbildungsansatz von Objekten auf eine relationale Datenbank wird oft auch als Teilnormalisierung bezeichnet.


11. Klassenmodell der Anwendung

Ein weiterer Bestandteil des Anwendungs-Designs ist das Klassenmodell. Dieses beschreibt die Komponenten einer Software und gibt einen Überblick über die Strukturierung innerhalb der einzelnen Bereiche. Es umfasst die Klassen und Beziehungen und stellt alle Services der Anwendung nach Außen dar.

Im Rahmen dieses Artikels kann jedoch kein vollständiges Klassen-Design erbracht werden. Dies ist erst bei vollständig bekannter Technologie, deren Tools und Mechanismen komplett möglich. Da der Artikel trotzdem ein Technologie-unabhängiges Design diskutieren möchte, zeigt das folgende Diagramm eine generische Übersicht der relevanten Klassen eines Gästebuchs:

Im Klassendiagramm wird davon ausgegangen, dass innerhalb der Präsentationsschicht das MVC-Pattern zum Einsatz kommt. Daher wurde für jeden View, der sich aus den essenziellen Use Cases ableitet, ein Controller angelegt. Diese nutzen den GuestbookService zum Anzeigen der Daten oder zur Speicherung der vom Benutzer eingegebenen Informationen. Um eine übersichtliche Abbildung zu erhalten, wurden die Klassen des Domänen-Modells nicht berücksichtigt. Wie bereits angesprochen, zählen diese jedoch zur Business-Schicht und sollten bei einer umfassenden Darstellung dort angesiedelt sein. Alle abgebildeten Klassen bilden zudem zu diesen eine use-Beziehung aus, da Domänen-Objekte der kompletten Anwendung bekannt sein müssen.

Der PagingService stellt einen Service für das Anzeigen einer blätterbaren Liste dar. Für diesen wurde wegen der sehr umfangreichen zu implementierenden Funktion eine eigene Klasse eingeführt, die unter Umständen in anderen Projekten wieder verwendet werden kann. Die Klasse GuestbookMapper implementiert das Mapping des mehrsprachenfähigen Datenmodells in das Domänen-Modell der Anwendung. Dabei greift er zur Anbindung einer Datenbank auf die Klasse DatabaseConnector zurück. Der Grund für die Auslagerung ist auch in diesem Fall die Möglichkeit der Wiederverwendung.


12. Fazit und Ausblick

Die in diesem Artikel beschriebene Software-Architektur bietet eine solide Grundlage für die Erstellung eines Technologie-gebundenen Detail-Designs. Der vorliegende Artikel ist daher sowohl als Teil der Projekt-Dokumentation als auch zur Abschätzung des Aufwands und zur Planung der Aufgaben geeignet.

Zudem wird widerlegt, dass für die Erstellung einer guten, objektorientierten Software-Architektur sehr detaillierte Kenntnisse in UML notwendig sind. Erfahrungsgemäß genügen Use Case-, Klassen- und Ablaufdiagramme bereits für 95% der Design-Beschreibungen. Die in einem UML-Diagramm nicht offensichtlich beschreibbaren Anforderungen lassen sich bequem als Ergänzung zu den Abbildungen einfügen.

Im nächsten Artikel dieser Serie wird das hier diskutierte Design um die Technologie-gebundenen Aspekte erweitert. In diesem Zusammenhang wird auch auf das bisher ausgesparte Thema Administration näher eingegangen. Um den Software-Lifecycle zu komplettieren, wird in der nächsten Ausgabe auch die Umsetzung des besprochenen Designs beschrieben. Dies umfasst insbesondere die Implementierung der Datenschicht und die Strukturierung der Komponenten der Präsentations-Schicht mit Hilfe des HMVC- und Page-Controller-Pattern.



14. Grafiken zum Download

Die Grafiken zum Artikel können unter http://media.adventure-php-framework.org/content/oo_guestbook_design_big_images.zip heruntergeladen werden.


Kommentare

Möchten Sie den Artikel eine Anmerkung hinzufügen, oder haben Sie ergänzende Hinweise? Dann können Sie diese hier einfügen. Die bereits verfassten Anmerkungen und Kommentare finden Sie in der untenstehenden Liste.
« 1   »
Einträge/Seite: | 5 | 10 | 15 | 20 |
1
viagra 19.10.2016, 19:40:07
It produces the day or available of buy cheap viagra online for women uk.
2
generic 12.09.2016, 11:12:14
3
generic_cialis 09.09.2016, 09:03:34
Hello!
generic cialis ,
4
generic_cia_lis 09.09.2016, 09:03:21
I truly appreciate this post. I have been looking all over for this! Thank goodness I found it on Bing. You've made my day! Thanks again!
5
generic_cialis 09.09.2016, 09:03:04
I truly appreciate this post. I have been looking all over for this! Thank goodness I found it on Bing. You've made my day! Thanks again!
6
generic_cialis 09.09.2016, 09:02:48
Hello!
generic cialis ,