Systemarchitektur
Im Folgenden werden das technische Konzept, sowie die Architektur des Systems beschrieben. Dazu werden zu Beginn die inhaltlichen Komponenten mit den entsprechenden Verbindungen textuell beschrieben. Daraufhin wird auf Basis des Content Models ein technisches Datenmodell erstellt. Abschließend werden das Datenmodell, sowie die Komponenten in einem Komponentendiagramm mit Datenfluss und Schnittstellen kombiniert, welches als Grundarchitektur für die Implementation dienen soll.
Die im Content Model aufgelisteten Entitäten bleiben bestehen. Zusätzlich werden für die in den Wireframes dargestellten Funktionalitäten weitere Inhalte benötigt. Da die Anwendung in der Lage sein soll eingekaufte Lebensmittel mit ihrer Haltbarkeit darzustellen, wird das "Produkt" eingefügt. Ein Produkt setzt sich aus einem Lebensmittel, sowie zusätzlich einem Einkaufsdatum und einem Haltbarkeitsdatum zusammen. Letzteres muss nicht das MHD sein, da dieses z.B. bei frischen Obst nicht vorhanden ist. Mehrere Produkte bilden eine Einkaufsliste, die nach der Auswahl von Gerichten entsteht. Die Einkaufsliste wird zusätzlich mit einem Erstelldatum versehen. Zuletzt werden die sogenannten "Challenges" eingeführt, welche Nutzer durch einen Gamification-Ansatz dabei unterstützen sollen weniger zu verschwenden. Diese sind immer an eine Gruppe geknüpft.
Das Datenmodell ergänzt das Content Model um die neu beschriebenen Inhalte, samt ihrer Datentypen, Variablennamen und Relationen zueinander. Formell wird dabei die Form eines UML-Klassendiagramms verwendet, da Flutter im Frontend eine objektorientierte Architektur unterstützt. Die Klassennamen und Variablennamen werden auf Englisch übersetzt, da dies auch in der Implementation der Fall sein wird.
Anders als das Datenmodell legt das Komponentendiagramm den Fokus auf die Bestandteile des Systems, sowie die technischen Schnittstellen und Kommunikationen.
