EXAM Test Automation Platform
Rich-Client-Architektur für HIL-Gerätekonfiguration und Automotive-ECU-Testautomatisierung
1) Projektkontext
MicroNova entwickelt Softwarelösungen für Testautomatisierung. Im Automotive-Umfeld wurde die EXAM-Plattform zur Erstellung, Konfiguration und Ausführung automatisierter Tests für elektronische Steuergeräte (ECUs) und Hardware-in-the-Loop-Testumgebungen eingesetzt.
Das Projekt war ein Neuprojekt auf Basis der Eclipse Rich Client Platform. Außer den grundlegenden RCP-/JFace-Technologien musste die eigentliche Applikationsarchitektur von Grund auf aufgebaut werden: Oberflächen, Editoren, Views, Datenmodelle, Synchronisationslogik, Hibernate-Anbindung, Import-/Exportfunktionen und grafische Abhängigkeitsdarstellung.
Der Kern der Aufgabe war nicht nur die Implementierung einzelner GUI-Fenster, sondern der Aufbau einer synchronisierten Engineering-Umgebung, in der grafische Modelle, logische Datenmodelle und Datenbankpersistenz konsistent zusammenarbeiten.
2) Fachliche und technische Herausforderung
HIL-Testsysteme bestehen aus vielen konfigurierbaren Geräten, Parametern, Abhängigkeiten und eindeutig identifizierbaren Objekten. Ingenieure müssen diese Konfigurationen sicher bearbeiten können, bevor sie in realen Testumgebungen verwendet werden.
- Konfiguration von HIL-Geräten und Testkomponenten
- Verwaltung von Parametern und deren Abhängigkeiten
- Eindeutige Identifikation technischer Konfigurationsobjekte
- Synchronisation zwischen grafischen Editoren, Tree Views, Property Views und Datenbankmodellen
- Wiederverwendbare Infrastruktur für zukünftige Testautomatisierungsfunktionen
3) Entwicklung einer RCP-Applikation von Grund auf
Die eigentliche Applikationslogik wurde im Projekt weitgehend neu entwickelt. Dazu gehörte der vollständige Aufbau der Bedienoberflächen, der internen Modelle, der View-Kommunikation und der Persistenzanbindung.
Neu entwickelte Komponenten
- Mehrere grafische Perspektiven
- Tree-, Table-, Property- und Editor-Views
- Grafische Dependency View
- JFace-basierte Steuerungs- und Zugriffsschicht
- Hibernate-Kommunikation und Persistenzworkflow
Architektonischer Schwerpunkt
- Zentrale Steuerung aller Views
- Synchronisierte GUI- und Datenmodelle
- Wiederverwendbare Controller-Strukturen
- Klare Trennung von Darstellung, Logik und Persistenz
4) Zentraler RCP Application Controller
Ich entwarf und implementierte einen zentralen Application Controller zur einheitlichen Steuerung der wesentlichen Eclipse-RCP- und JFace-Komponenten.
Gesteuerte UI-Komponenten
- Tree Views
- Property Views
- Table Views
- Editor Views
- Dependency Views
Zweck der Architektur
- Zentrale Verarbeitung von Benutzeraktionen
- Reduzierte Kopplung zwischen Views
- Konsistentes Update-Verhalten
- Wiederverwendbare JFace-Integrationsschicht
Statt direkte Punkt-zu-Punkt-Kommunikation zwischen einzelnen Views und Editoren zu implementieren, wurden alle Komponenten über eine gemeinsame Steuerungsschicht koordiniert. Dadurch wurde die Applikation erweiterbarer, wartbarer und deutlich weniger anfällig für doppelte Synchronisationslogik.
5) Synchronisierte GUI- und Datenmodellarchitektur
Ein zentraler Teil meiner Arbeit war die Implementierung einer synchronisierten Architektur zwischen grafischer Oberfläche, logischem Datenmodell, Hibernate-Modell und Datenbank.
GUI-Modell
↓
Logisches Datenmodell
↓
Hibernate-Persistenzmodell
↓
Datenbank
Änderungen in Editoren wurden zunächst im grafischen bzw. logischen Modell abgebildet. Über eine Observer-/Provider-Architektur wurden abhängige Views automatisch benachrichtigt und aktualisiert. Erst nach einem expliziten Speichervorgang wurden die zuständigen Hibernate-Modelle aktualisiert und dauerhaft in der Datenbank persistiert.
Die Architektur stellte sicher, dass grafische Darstellung, logische Konfigurationsdaten und Datenbankzustand konsistent blieben, ohne dass jede View jede andere View direkt kennen musste.
6) Ereignisgesteuerte Observer-/Provider-Architektur
Zur Verteilung von Änderungen zwischen Editoren, Views und Datenmodellen implementierte ich einen ereignisgesteuerten Observer-/Provider-Mechanismus.
- Change Notifications von Editoren an abhängige Views
- Activity- und State-Handling für JFace-Komponenten
- Zentrale Weitergabe von Modelländerungen
- Konsistentes Refresh-Verhalten für Tree-, Property-, Table- und Dependency-Views
7) Dependency View und Beziehungen technischer Objekte
Ich entwarf und implementierte eine grafische Dependency View zur Darstellung von Beziehungen zwischen HIL-Konfigurationsobjekten, Parametern und Testkomponenten.
Diese View war kein isoliertes Zusatzfenster, sondern vollständig in die zentrale Synchronisationsarchitektur eingebunden und reagierte automatisch auf Änderungen im zugrunde liegenden Datenmodell.
- Grafische Darstellung von Abhängigkeiten zwischen Testobjekten
- Unterstützung eindeutig identifizierbarer Konfigurationselemente
- Integration mit Tree View und Property View
- Bessere Transparenz bei komplexen HIL-Konfigurationen
8) Datenbankpersistenz mit Hibernate
Hibernate wurde als Persistenz-Framework eingesetzt. Ich verband die Applikationsdatenmodelle mit der Hibernate-Schicht, sodass bearbeitete Engineering-Objekte kontrolliert und konsistent gespeichert werden konnten.
Der Speicherworkflow war bewusst explizit aufgebaut: Benutzeränderungen wurden zunächst innerhalb des Applikationsmodells gesammelt und synchronisiert. Erst bei einer Save-Aktion wurden die verantwortlichen Hibernate-Modelle aktualisiert und persistiert.
9) Implementierte Engineering-Funktionen
- Grafische Benutzeroberflächen für mehrere Benutzerperspektiven
- Spezialisierte Editoren mit Tabellen- und Baumstrukturen
- Views mit Baumstrukturen zur detaillierten Darstellung
- Wiederverwendbare Datenmodelle für Editoren und Views
- Event Handler für Komponentenbenachrichtigung und Zustandsänderungen
- Model-View-Controller-basierte GUI-/Datenmodellarchitektur
- Create-, Copy-, Edit- und Delete-Operationen für Testkomponenten
- Generalisierung gemeinsamer GUI- und Datenmodellkomponenten
- Grafische Drag-&-Drop-Unterstützung für Testknoten und Parameter
- Find-&-Replace-Funktionalität in Editoren
- Asynchrone Speicherung von Benutzeränderungen in der Datenbank
- Globales Fehlerhandling mit Warnungen und Fehlerausgabe
- Export-Wizard für Testsequenzen mit Apache POI / Excel
- Import-Wizard für XML-basierte Testparameterdaten
10) Technologien
- Java
- Eclipse Rich Client Platform (RCP)
- SWT / JFace
- Hibernate
- Apache POI
- XML
- Observer-/Provider-Pattern
- Model-View-Controller
- Zentraler Application Controller
- Rich Client Architecture
11) Architektonisches Ergebnis und Mehrwert
- Wiederverwendbares Framework für synchronisierte Eclipse-RCP-Views und Editoren
- Klare Trennung von GUI-Modell, logischem Modell und Persistenzschicht
- Zentrale Steuerung von Tree-, Property-, Table-, Editor- und Dependency-Views
- Konsistente HIL-Gerätekonfiguration mit Parameterabhängigkeiten und Objektidentifikation
- Verbesserte Wartbarkeit durch ereignisgesteuerte Synchronisation
- Skalierbare Grundlage für zukünftige EXAM-Testautomatisierungsfunktionen
Das Projekt zeigt den Aufbau einer skalierbaren Rich-Client-Plattformarchitektur: nicht nur GUI-Implementierung, sondern eine synchronisierte Engineering-Umgebung mit zentraler Steuerung, wiederverwendbaren Datenmodellen, grafischer Dependency View und kontrollierter Datenbankpersistenz.