Hinweise zum SE2-Meilenstein 'Persistenz'

0. Abgabe

Schriftliche Abgabe (während Corona: bitte keine Zip-Dateien schicken, sondern nur PDFs):

1. Deckblatt mit dem Namen der Veranstaltung, des Meilensteins und Ihrer Gruppe, der Liste der Gruppenmitglieder sowie einer Mailadresse, um die Gruppe bei Bedarf kontaktieren zu können

2. Bisheriges Klassendiagramm mit allen Bearbeitungen aus der Checkliste des  ersten Meilensteins

3. Dokumentation ("Changelog") der Funktionalität dieser Persistenzschicht (siehe unten) mit abgebildeten Ausschnitten aus Ihrem Klassendiagramm

4. Erweitertes Klassendiagramm mit der Persistenzschicht (siehe unten)

1. Persistenzschicht

1. Auswahl einer (fast) beliebigen Klasse Ihres Entwurfsmodells: Einzige Bedingung ist, dass diese Klasse eine zu persistierende Containerklasse sein muss , also mindestens eine To Many -Assoziation enthält, mit der sie zur Laufzeit eine Menge anderer Objekte verwaltet, also beispielsweise Lieferant→viele Artikel (Beispiel des Vorlesungsvideos), Kalender→viele Termine, Chat→viele Nachrichten, Rezept→viele Zutaten, Rezeptcontainer→viele Rezepte.
Hinweis: Der Sinn dahinter ist, dass Sie das VirtualProxy Pattern (siehe unten) nur bei einer Containerklasse richtig anwenden können ( lazy loading geschieht nur, wenn eine Menge von Objekten geladen werden soll).

2. Einbau des Database Broker Patterns , um das Materialisieren und das Dematerialisieren von Objekten der gewählten Containerklasse zu ermöglichen. Da das Manuskript und das Vorlesungsvideo nur den Vorgang des Materialisierens beschreiben, müssen Sie für das Dematerialisieren weitere Methoden hinzufügen , beispielsweise dematerialize() und einige mehr. Das ist eine der Herausforderungen dieses Meilensteins.

3. Einbau des VirtualProxy Patterns , um das nachladende Materialisieren assoziierter Objekte (z.B. viele Artikel, viele Termine, viele Nachrichten, viele Zutaten, viele Rezepte) der gewählten Containerklasse verzögert ( lazy loading) zu ermöglichen. Hierzu ist es erforderlich, die Containerklasse durch Vererbung zu erweitern, um in der abgeleiteten Klasse die erforderlichen Getter-Methode(n) zu ergänzen.
Hinweis: Bei dieser Vererbung spielt das Konzept der Reflection API (siehe unten) eine Rolle.

4. Einbau des ObjectCache Patterns , um das bedingte Dematerialisieren eines Objekts der gewählten Containerklasse beim Commit der Datenbanktransaktion gemäß seines Cache-Zustands zu ermöglichen. Auch hierzu ist es erforderlich, zum Ergänzen der erforderlichen Setter-Methode(n) die Containerklasse zu erweitern.

2. Dokumentation

1. Beschreibung eines Dematerialisierungsvorgangs ( welche Methoden in welchen Klassen werden in welcher Reihenfolge aufgerufen und welche Aufgaben erledigen sie?) anhand des von Ihnen modellierten Database Broker Patterns

2. Beschreibung eines verzögerten Nachladens anhand des von Ihnen modellierten VirtualProxy Patterns ( was, wann und durch welche Methodenaufrufe geschieht es?). Denken Sie in diesem Zusammenhang an das  Java Reflection API und die erweiterte Containerklasse PersistenceBagLieferant (so nennt ein Persistence Framework typischerweise die erweiterte Beispielklasse) mit der in ihr erweiterten Getter-Methode(n).

3. Beschreibung eines vermiedenen Dematerialisierens beim  Commit der Datenbanktransaktion anhand des von Ihnen modellierten ObjectCache Patterns ( was, wann und durch welche Methodenaufrufe geschieht es?). Denken Sie auch hier an das Java Reflection API und die erweiterte Containerklasse mit der in ihr erweiterten Setter-Methode(n).

Hinweis: Das unüberlegte Kopieren der Patterns aus dem Foliensatz bzw. Vorlesungsvideo in Ihr Klassendiagramm führt zu keinem sinnvollen Meilensteinergebnis, wie Sie an Ihrer Dokumentation selbst erkennen werden. Das Modell muss modifiziert werden, damit das, was Sie in der Dokumentation beschreiben, tatsächlich funktionieren kann.