P3: Architektur

Zugegebenermaßen, ich habe mich die letzten paar Tage nicht mit dem Blog beschäftigt (weder dem eigenen noch jenen der anderen Kollegen aus SWA) . Erst jetzt nach der Abgabe von P3, bemerkte ich dass wir eigentlich etwas gezeichnet haben, dass sich von den anderen Entwürfen sehr stark unterscheidet.

Im nächsten Eintrag werde ich dann einen Review zur Architektur von Team 2 aus Gruppe 4 posten, und damit auch ein wenig begründen warum unser Diagramm so anders ist.

Da die Deadline ohnehin schon vorbei ist, stelle ich hier einmal unsere Variante vor, wobei die Erläuterungen aus der Abgabe 1:1 kopiert sind.



Das System verwendet das Presentation-Abstraction-Control Pattern für seine grundlegende Architektur. Im Groben orientiert sich diese an den Ideen des JBoss Seam Frameworks.

Der Presentation Layer wird dabei von einem Pull-basiertem Template-System und einer Presenter-Klasse gebildet, die die PHP Objekte on Demand zur Verfügung stellt und für den Pageflow sowie Fehler- und Erfolgsmeldungen verantwortlich ist. Die Zuordnung zwischen Template-Variable und Backing Bean dabei über den Klassennamen bzw. Attributsnamen. Das Importieren von Objekten erfolgt dabei über Schnittstellen zur Cotrol Komponente.

Der Control Layer übernimmt die Steuerung der Webanwendung und verbindet die beiden anderen Layer Abstraction und Presentation. Zentraler Einstiegspunkt ist der Front Controller mit integriertem Request Dispatcher. Bei jedem HTTP Request wird die korrespondierende Methode der Anwendungslogik aufgerufen, und benötigte Request Parameter als Argumente übergeben. Zur Entkopplung "echter Business-Logik" und Web-Programmierung bietet dieser Layer auch Schnittstellen für Authentifizierung, Rechtemanagement, und Verwaltung der Session.

Der Application Layer ist für die eigentliche Business-Logik zuständig. Die "Application Logic" Komponente beinhaltet dabei alle Klassen zur Umsetzung der funktionalen Anforderungen, deren Methoden sind die Implementierung von Anwendungsfällen und werden vom Front Controller gestartet.

Das Objektmodell wird im Subsystem Model realisiert. Im Paket "Entity" befinden sich (analog zu POJOs) die Klassen zur Abbildung der Realität mit entsprechenden Attributen und dazugehörigen gettern und settern. Diese können von der Applikationslogik über eine Factory instanziert werden. Der Persistence Manager übernimmt das Laden und Speichern der Objekte im gewünschten Persistenzsystem, also zB einer relationalen Datenbank oder XML-Dateien. Die dafür benötigten Meta-Informationen (Spaltennamen, ...) werden dabei entweder über Konvention (Klassenname == Tabellenname, Attributname == Spaltenname, ...) oder Annotationen festgelegt.