-
Notifications
You must be signed in to change notification settings - Fork 0
Meeting 4
Team: T4
- Prahbdip Singh
- Emma Danko
- Maria Kuhn
- Adriano Paganini
- Fabienne Schedler
Datum & Uhrzeit: 17.03.2026, 16:15–17:00
Meeting-Typ: online
Ort: Discord
Schriftführerin: Fabienne Schedler
- Genaues Feedback zu Konzept V1 durcharbeiten
- Vorbereitung der Anpassungen für Konzept V2
- Überblick über den aktuellen Stand von Konzept V2
- Klärung, welche Teile und Überarbeitungen bis zur V2-Abgabe am 19.03.2026 noch fertiggestellt werden müssen
Im Meeting wurde vereinbart, dass am 18.03. um 11:00 Uhr eine Probe für den Durchstichtag stattfinden soll. Ziel dieses Termins ist es, den aktuellen Stand des Systems gemeinsam zu testen und sicherzustellen, dass alle grundlegenden Komponenten funktionieren.
Anschließend wurden verschiedene komplexe Abläufe des Systems besprochen. Dabei ging es insbesondere um den Umgang mit Grenzwertverletzungen. Diskutiert wurde, wie erkannte Grenzwertverletzungen wieder aufgehoben werden können und wie diese im System dargestellt werden sollen. Ebenso wurde der Ablauf beim Löschen von Benutzer:innen betrachtet und welche Auswirkungen dies auf die gespeicherten Daten haben kann.
Im Zusammenhang mit Grenzwerten wurde außerdem überlegt, wie Hinweise (Climate Hints) organisiert werden sollen. Dabei wurde diskutiert, ob mehrere Hinweise für unterschiedliche Grenzwerte möglich sein sollen. Als möglicher Ansatz wurde festgehalten, dass jeder Raum eigene Thresholds besitzt, wobei ein Upper Bound verpflichtend ist und ein Lower Bound optional sein kann. Zusätzlich sollen drei grundlegende Climate Hints vorhanden sein, während Manager:innen weitere Hinweise flexibel erstellen und den jeweiligen Situationen zuordnen können.
Darüber hinaus wurde das UML-Diagramm gemeinsam durchgesehen und offene Fragen zur Modellierung einzelner Beziehungen diskutiert. Auch der Abschnitt zur Ausfallssicherheit wurde besprochen. Dabei wurden insbesondere Szenario 3 und Szenario 4 genauer betrachtet. In Szenario 3 ging es um den Umgang mit Messdaten sowie gepufferten Daten bei bestimmten Ausfällen. Für Szenario 4 wurde zusätzlich die Frage diskutiert, was passiert, wenn der Speicherpuffer des Raspberry Pi vollständig ausgelastet ist.
Zum Abschluss wurden noch sogenannte Keep-Alive-Szenarien besprochen. In diesem Zusammenhang wurde überlegt, wie diese Abläufe im System dargestellt und in Form von Sequenzdiagrammen dokumentiert werden können.
| Aufgabe | Zeitspanne | Verantwortlichkeit |
|---|---|---|
| Aufbereitung Feedback für Konzept V2 | - | Alle |
| Darstellung Warnungen in GUI | - | Alle |
| Use Case Beschreibungen updaten | - | Maria Kuhn |
| UML updaten | - | Adriano Paganini |
| RPi Webserver aufsetzen | - | Emma Danko |
| Use Case Diagramme updaten | - | Prahbdip Singh |
| Frontend für Durchstichtag | - | Fabienne Schedler, Maria Kuhn |
| GUI Verlaufsdiagramm keine Daten Prototyp | - | Fabienne Schedler |
Liebes Team G5T4,
hier meine Anmerkungen zu eurem Konzept V1.
Eine wirklich sehr saubere und ausführlich ausgearbeitete V1 des Konzepts.
Alle geforderten Teile sind detailliert ausgearbeitet, alle Diagramme sind beschrieben (sehr gut).
Ihr habt bereits getroffene Annahmen und Entscheidungen dokumentiert und euch augenscheinlich intensiv mit der Aufgabenstellung auseinandergesetzt.
Sehr gut und übersichtlich.
Kleine Anmerkung:
- Im Systemüberblick sind Implementierungs- bzw. PS-Details enthalten, die für ein Softwarekonzept an dieser Stelle nicht unbedingt relevant sind.
-
Was bedeutet „verwalten“ bei Abwesenheiten?
z.B. können auch vergangene Abwesenheiten „verwaltet“ werden? -
Doppelter UC bei Mitarbeiter:innen?
„Historische Raumdaten anzeigen (gemeinsame Bereiche der eigenen Abteilung)“ und
„Historische Daten anzeigen (gemeinsame Bereiche, volle Granularität)“. -
Was beinhaltet „registrieren“ in z.B. UC „Raspberry Pi registrieren“?
-
Wie bekommt eine Abteilung einen Abteilungsleiter?
-
Was sind „Geräte“ in „Geräte für Räume einrichten“?
-
Wer sieht, welche Geräte im System momentan online sind? (siehe Klassendiagramm)
-
UC am Raspberry bzw. der Sensorstation?
-
Darüber, ob ein Systemteil Akteur ist, kann diskutiert werden.
-
Technische Designentscheidungen sollten separat dokumentiert werden; sie sind für Use-Case-Beschreibungen meist irrelevant.
-
In der Vorbedingung fehlt:
Raum hat permanente Belegung ≥ 5 Personen. -
Welche Daten werden hier betrachtet?
Nur die aktuellen Messwerte oder aktuelle und historische Messdaten?
(laut GUI-Prototyp beides?) -
Historische Messwerte können jederzeit eingesehen werden
(d.h. Verlaufsansichten können auch dann angezeigt werden, wenn keine aktuellen Daten vorhanden sind). -
Muss das System explizit auf Datenschutz prüfen?
Laut Aufgabenbeschreibung dürfen im Backend nur datenschutzkonforme Daten sein.
Wenn keine aktuellen Daten vorhanden sind, werden eben keine angezeigt.
„Aktuelle Messwerte, Anzahl aktiver Warnungen“ vs.
„Erhält zusätzlich eine Übersicht aller Räume der eigenen Abteilung in reduzierter Datengranularität (Tagesdurchschnitte für Büroräume)“ aus der Systemübersicht.
„Webapp: Warnung wird prominent für alle Nutzer:innen des betroffenen Raums angezeigt, inkl. konfiguriertem Raumklima-Tipp.“
- Gibt es dazu noch keine Entscheidung?
- Im GUI-Prototyp steht „Banner“?
Measurement
Annahmen aus dem Klassendiagramm:
- Sensorstationen werden nie um Sensoren erweitert.
- Alle Messdaten sind zu jedem Messzeitpunkt vorhanden.
→ d.h. potentiell sind Felder Null.
-
Jedes Mal, wenn ich einen Messwerttyp sehen will, muss ich alle Messwerte aus der Datenbank holen.
-
Single Responsibility Principle?
-
Ihr habt ja schon „Metric“ und entsprechend eine schöne Modellierung für Thresholds.
ThresholdViolation
- Wird Über- bzw. Unterschreitung als Typ errechnet?
Änderungsvorschlag:
Sensor als eigene Klasse modellieren:
- Typ
- Assoziation zu SensorStation
- Assoziation zu Measurement
- leicht erweiterbar
-
Es fehlt: Department Manager
-
Ist ein Department notwendigerweise auf ein Gebäude beschränkt?
d.h. ist das eine realistische Annahme/Einschränkung? -
Braucht jeder Raum zwingend einen Raspberry Pi?
(Beschreibung sagt 0..1) -
Warum zwei Aggregationen zwischen
Raum und Raspberry Pi bzw. Raspberry Pi und SensorStation?
Aggregation: A beinhaltet B
→ hier: beinhaltet B auch A?
Assoziationen werden als bidirektional angenommen.
-
Room ist stabil, d.h. Teil eines physischen Gebäudes.
-
Thresholds und SensorStations sind mit spezifischen Räumen assoziiert bzw. sogar physikalisch in einem spezifischen Raum.
-
Raspberry ist ein Teil des Systems.
Momentan gilt zwar 1 Raspberry – 1 Raum, aber das kann sich jederzeit ändern
(z.B. Raspberry wird ausgetauscht).
→ SensorStations hängen an Räumen, nicht nur an Raspberries.
→ Thresholds hängen an Räumen, nicht an Raspberries.
„RaspberryPi 1 * SensorStation:
Ein Raspberry Pi kann mehrere Sensorstationen verwalten (im Prototyp: eine pro Raum).“
Nur zur Sicherheit:
Im Webapp kann ein Raspberry beliebig viele Sensorstationen haben, auch im Prototyp?
„Wird eine Sensorstation gelöscht, werden ihre Messdaten ebenfalls gelöscht (CASCADE).
Historische Grenzwertverletzungen bleiben erhalten (roomId-Referenz bleibt bestehen).“
→ sehe ich kritisch.
Messdaten gehören zum Raum und damit zum Gebäude.
Die SensorStation mit ID „12345“ kann aus unterschiedlichsten Gründen gelöscht werden.
Warum entziehe ich mir meine Datengrundlage für längerfristige Analysen, nur weil ich z.B. ein defektes Gerät austauschen muss?
Wie sehen Ansichten aus, wenn temporär aus Datenschutzgründen keine aktuellen Daten angezeigt werden dürfen?
Durchstich-Demonstration ist am 23.03. (Start KW 13).
→ M1: Hardware Setup in KW 14–15 kommt zu spät.
-
KW 16–17 als Deadline für die Backend Basics ist sehr spät.
Ihr braucht dafür sicher keinen Monat, habt dann aber nur mehr ein bisschen über 1 Monat Zeit. -
Abschlussbericht ist heuer nicht Teil der Abgabe.
-
Ich würde die Testdaten-Erstellung vorziehen bzw. mehrmals machen, damit ihr zumindest laufend eure GUI und eure DB testen könnt
(z.B. wird übermäßig viel Eager Fetching betrieben und es entstehen dadurch Performance-Probleme).