Software-Architektur – Trockenprogrammsteuerung

Dieses Dokument beschreibt die Architektur der Software zur Steuerung von Trockenprogrammen im Wäschetrockner. Es werden die wichtigsten Komponenten, deren Aufgaben, Schnittstellen und die wichtigsten Änderungen im Verlauf der Entwicklung transparent dokumentiert.

---

1. Architekturübersicht

Die Anwendung ist als JavaFX-Desktopanwendung realisiert und folgt einer klaren Trennung zwischen Logik (Simulation, Steuerung, Sicherheit) und Benutzeroberfläche (Scenes). Die Architektur ist modular aufgebaut und unterstützt Erweiterbarkeit sowie Testbarkeit.

Hauptkomponenten

• DryerState
  Zentrale Datenhaltung für den aktuellen Zustand des Trockners (Programm, Status, Temperatur, Feuchte, Tür, Fehler, Event-Log).
  Enthält Logging-Mechanismus für Traceability (REQ-011).

• DryerSimulation
  Simuliert den Trocknungsprozess für verschiedene Programme. Steuert Temperatur, Feuchte, Restlaufzeit und interagiert mit dem SafetyModule.
  Implementiert die Feuchtesensorintegration und dynamische Restlaufzeit (REQ-005, REQ-004).

• SafetyModule
  Kapselt alle Sicherheitsfunktionen: Türverriegelung, Überhitzungsschutz, Türöffnung nur bei sicherer Temperatur.
  Überwacht und steuert Türstatus und Sicherheitsabschaltungen (REQ-003, REQ-002).

• ProgramManager
  Koordiniert Simulation und Zustand, steuert das Haupt-Update-Loop im Hintergrundthread.
  Schnittstelle zwischen GUI und Simulation.
  Implementiert das Nachladen neuer Wäsche (REQ-010).

• GUI (Scenes)

  • ProgramSelectionScene: Auswahl des Programms, Türsteuerung, neue Wäsche einlegen (REQ-001, REQ-010).
  • RunningScene: Anzeige des laufenden Programms, Status, Restlaufzeit, Temperatur, Feuchte, Abbruchmöglichkeit (REQ-004, REQ-006, REQ-012).

---

2. Erster Grobentwurf der Architektur

Das folgende Blockdiagramm zeigt die Struktur und Beziehungen zwischen den Komponenten:

Verbindungen zwischen Komponenten stellen Abhängigkeiten oder Informationsaustausch dar. Pfeilrichtungen wurden weggelassen – Beziehungen sind bidirektional interpretierbar, sofern nicht anders spezifiziert.

3. Endgültige Software-Architektur

Klassendiagramm

Sequenzdiagramm

---

4. Wichtige Architekturentscheidungen & Änderungen

Iteration 2 → 3: Erweiterungen und Änderungen

• Logger/Traceability:
  In DryerState wurde ein Event-Log und File-Logging eingeführt. Alle wichtigen Ereignisse (Start, Stop, Fehler, Türaktionen) werden protokolliert (REQ-011, REQ-009).

• Neue Wäsche einlegen:
  Über ProgramManager.loadNewLaundry() und die GUI kann nach Programmende bei geöffneter Tür neue Wäsche geladen werden. Die Feuchtigkeit wird zurückgesetzt, ein Event geloggt (REQ-010).

• Abkühlfunktion:
  Nach Programmende wechselt der Status in COOLING. Die Tür bleibt verriegelt, bis die Temperatur unter 40°C fällt (SafetyModule.SAFE_DOOR_TEMPERATURE). Erst dann kann die Tür geöffnet werden (REQ-012).

• Türsteuerung:
  Die Tür kann nur geöffnet werden, wenn sie nicht verriegelt ist und die Temperatur sicher ist. Die Logik ist im SafetyModule gekapselt.

• Testbarkeit:
  Für alle Kernmodule existieren JUnit-Tests, die die Funktionalität und Sicherheitsmechanismen abdecken.

---

5. Schnittstellen & Zusammenwirken

• ProgramManager ist die zentrale Schnittstelle zwischen GUI und Simulation.
• DryerSimulation und SafetyModule arbeiten eng zusammen, um Sicherheit und realistische Simulation zu gewährleisten.
• Scenes greifen ausschließlich über den ProgramManager auf den Zustand zu.

---

6. Erweiterbarkeit

Die Architektur erlaubt es, weitere Programme, Sensoren oder Sicherheitsfunktionen modular zu ergänzen. Neue Szenen können einfach hinzugefügt werden, da die Logik klar getrennt ist.

---

7. Fazit

Die Architektur ist nach den Prinzipien der Modularität, Nachvollziehbarkeit und Sicherheit gestaltet. Alle Änderungen und Erweiterungen aus Iteration 3 sind nachvollziehbar dokumentiert und im Quellcode sowie in den