Eine Anwendung zur Heizungsanalyse entwickeln

Bei EWUS suchten Ingenieure nach Möglichkeiten, bestehende Heizungsanlagen effizienter zu betreiben. Dafür entwickelte ich eine Webanwendung, die Anlagen- und Messdaten zusammenführt, Analysen automatisiert und deren Ergebnisse vor dem Speichern zur Prüfung vorlegt.

Das Projekt mit React, Java und Spring Boot entstand 2021 im Rahmen meiner Bachelorarbeit an der HTW Berlin. Drei Entscheidungen verbinden Anforderungen, Architektur und Benutzeroberfläche: Was lässt sich sinnvoll automatisieren? Wo liegen die Systemgrenzen? Und wie prüfen Ingenieure die Ergebnisse?

Erst das Ergebnis klären, dann automatisieren

Die erste Version sollte vier Analysen abdecken: Dimensionierung, Nutzungsgrad, Rücklauftemperatur und die Temperaturspreizung zwischen Vor- und Rücklauf.

In Gesprächen mit meinem betrieblichen Betreuer überführten wir die Arbeitsabläufe der Ingenieure in Szenarien, User Stories und Akzeptanzkriterien. Eine Anforderung bestimmte große Teile des Entwurfs: Generierte Vorschläge müssen geprüft werden, bevor sie vorhandene Analysetexte ersetzen. Die erste Version sollte die Ingenieure unterstützen; vollständige Automatisierung war ein späterer Schritt.

Damit wurde der Umfang konkret: Eine Analyse musste einen Vorschlag liefern, den ein Ingenieur prüfen, bearbeiten und übernehmen konnte. Aus „eine Analyse ausführen“ wurde ein Ablauf, der sich umsetzen und mit den vorgesehenen Nutzern bewerten ließ.

Zuständigkeiten vor Servicegrenzen klären

Der Datenzugriff war auch für andere Anwendungen nützlich. Deshalb trennte ich einen Anlagen-Service, der Informationen aus bestehenden Systemen zusammenführte, von einem Analyse-Service für Berechnungen und deren Konfiguration. Ein React-Frontend bildete den Arbeitsablauf ab.

Die Services übernahmen bewusst größere Aufgabenbereiche und kommunizierten über HTTP und JSON. Die Analysekonfiguration blieb im Analyse-Service und brauchte kein eigenes Deployment. Die Arbeit vergleicht monolithische, serviceorientierte und Microservice-Architekturen. Praktisch entscheidend war jedoch, welche Grenzen Wiederverwendung ermöglichen, ohne unnötigen Betriebsaufwand zu schaffen.

Innerhalb dieser Grenzen half Model–View–Controller bei der Strukturierung von React-Ansicht, Controllern für Anfragen und separater Modell- beziehungsweise Anwendungslogik. Spring-Data-JPA-Repositories übernahmen die Persistenz. Durch Convention over Configuration musste ich weniger Einstellungen selbst festlegen; verständliche Fachbegriffe und fokussierte Methoden machten die anwendungsspezifischen Teile leichter nachvollziehbar.

Die API verband ressourcenorientierte Konfiguration mit einem Aufruf für Sammelanalysen, der eine Auswahl von Anlagen entgegennahm. Diesen Aufruf beschreibt die Arbeit als RPC-artig neben den REST-orientierten Endpunkten: Die Schnittstelle bildete die Analyse als ausdrückliche Aktion ab.

Heute würde ich diesen Entwurf auch mit einem modularen Monolithen vergleichen: Klare Zuständigkeiten erfordern keine getrennten Prozesse. Ausschlaggebend sind Wiederverwendung, Verantwortung im Team und der Aufwand für Bereitstellung und Änderungen. Fowlers Überlegungen zu „Monolith First“ geben dieser Abwägung weiteren Kontext.

Die Prüfung in die Oberfläche einbauen

Die Ingenieure waren an Tabellen und Anlagenkennungen gewöhnt. Die Oberfläche knüpfte daran an: vorhandene Texte neben generierten Vorschlägen, bearbeitbare Ergebnisse und eine ausdrückliche Bestätigung vor dem Speichern.

In einer zweiten Ansicht konnten Ingenieure auswählen, welche Analysen je Anlage ausgeführt werden. Änderungen an mehreren Anlagen erschienen zunächst in der Tabelle und wurden erst nach einer gesonderten Bestätigung gespeichert. So blieb auch bei Sammeländerungen Gelegenheit zur Prüfung.

Dieses Muster hilft überall dort, wo Software folgenreiche Änderungen vorschlägt: Ergebnisse und relevanten Kontext gemeinsam anzeigen und die Bestätigung direkt dort ermöglichen. Auch nach einer technisch erfolgreichen Anfrage muss der Mensch verstehen können, was passiert ist.

Vertrauen durch Feedback aufbauen

Tests mit JUnit, Mockito und einer HyperSQL-Testdatenbank prüften das Verhalten des Backends. Spotless und ESLint unterstützten einheitlichen Code. Das Frontend prüfte ich manuell; zwei Personen aus der Zielgruppe probierten die Anwendung ohne vorherige Einführung aus. Ihre Rückmeldungen zeigten konkrete Verbesserungen: den Zustand einer Ansicht erhalten, Auswahlen zwischen Ansichten übernehmen und vor dem Verlust ungespeicherter Änderungen warnen.

Automatisierte Tests und Rückmeldungen der Nutzer beantworteten unterschiedliche Fragen: Verhalten sich Berechnungen und Persistenz wie erwartet? Und funktioniert der Arbeitsablauf in der Praxis? Die Bachelorarbeit benannte außerdem wiederholte manuelle Prüfungen, die sich automatisieren ließen.

Das Ergebnis war ein funktionsfähiger Prototyp mit vier Analysen, wiederverwendbarem Datenzugriff und einem Prüfablauf. Dass die Anwendung Ingenieure beim effizienteren Betrieb von Heizungsanlagen unterstützt, machte das Projekt für mich besonders sinnvoll.

Nach der Bachelorarbeit

Nach der Bachelorarbeit entwickelte und betreute ich die Anwendung weiter. Zwischen 2022 und 2025 ergänzte ich Fehlererfassung mit Sentry und verbesserte die Datenanbindung und Fehlerbehandlung. Damit ließen sich Fehler auch bei fortlaufenden Änderungen an der Anwendung leichter untersuchen.

2024 richtete ich Docker und Docker Compose für Builds und die lokale Entwicklung ein. Dazu kamen GitHub-Actions-Workflows, die die Backend-Services bauen und auf Azure Container Apps bereitstellen. Die Deployments verknüpfte ich außerdem mit der Release-Erfassung in Sentry, um gemeldete Fehler der bereitgestellten Softwareversion zuordnen zu können.

Bachelorarbeit und Quellcode

Die vollständige Arbeit und der ursprüngliche Frontend-/Backend-Code von 2021 dokumentieren die ursprüngliche Umsetzung im Detail. Das PDF der Bachelorarbeit enthält den Architekturvergleich, die Demonstration und die Evaluierung. Die Bilder oben sind die ursprünglichen Abbildungen 6.2 und 6.3.