Blog 4

[GalacticCodeGambit]

Blog 4

Klassendiagramm:

Klassendiagramm

Warum wir LSP benutzen:

Robuste Vererbung: Unterklassen sind wirklich Ersatz für Basisklassen
Zuverlässigkeit: schützt vor unerwarteten Laufzeitfehlern

aktualisierte Sequenzdiagramme:

Rezepte filtern:

Sequenzdiagramm

Zutaten eintragen:
Sequenzdiagramm

Erledigte Aufgaben

• Neue User Storys, Difinition of Done festgelegt, Story Points geschätzt
• SRS und Readme überarbeitet
• Issue Template erstellt für UserStorys

[sebo-dev]

Hey LazyCook,

mir gefällt, dass ihr im Klassendiagramm bewusst zwischen Benutzer und Admin unterscheidet und nicht alles unter einem generischen „User“ zusammenfasst. So werden die Rollen klar abgegrenzt und man erkennt, dass ihr euch früh Gedanken über Rechte und Verantwortlichkeiten gemacht habt.

Das Sequenzdiagramm „Zutaten eintragen“ ist ebenfalls richtig stark, vor allem weil ihr Fehlerfälle wie „Zutat nicht gefunden“ oder eine ungültige Mengenangabe mit eingebaut habt. Dadurch wirkt der Ablauf sehr nah an dem, was später tatsächlich im System passieren soll.

Eine kleine Anmerkung noch zum LSP-Teil: Ihr bleibt dort recht allgemein. Wenn ihr kurz ein konkretes Beispiel aus eurem Modell ergänzt, wird der Abschnitt anschaulicher und es wird deutlicher, wie ihr das Prinzip in eurem Projekt anwendet.

LG Sebo von DualNet!

[Finn1574]


Moin, starke Diagramme – besonders „Zutaten eintragen“ mit realistischen Fehlerpfaden.



Beim Filtern würde ich noch die Schichten sauber ziehen: UI ruft filterNachZutaten(zutatenListe, personenanzahl) in der LazyCookVerwaltung auf; die DB liefert nur Treffer, Logik bleibt in der Verwaltung.

Entkoppelt das Domänenmodell: Persistenz raus aus Rezept, stattdessen RezeptRepository/ZutatRepository; Verwaltung hängt an Interfaces. Nutzt List/Set statt Arrays und eine Enum für Einheiten, damit Validierung/Umrechnung zentral bleiben.

Kohäsion: Rezept nur Fachlogik; Rechteprüfung als AuthorizationService, nicht in Admin.

LSP: Methoden gegen Person ohne instanceof; entscheidet euch für Subklassen oder Role-Enum – nicht beides. Einheitliche Benennung (entweder Deutsch oder Englisch, camelCase, überall „LazyCookVerwaltung“); generische „Datenbank“-Klasse durch Repositories ersetzen.
Verknüpft jede User Story mit genau einem Sequenzfluss (Happy Path + ein Fehlerfall) und passenden Akzeptanzkriterien – dann ist eure DoD messbar.



Mit freundlichen Grüßen Finn.