Combined Draft 1

Merge luca into advancedSE
Draft 1 docu
2025-05-28 23:21:48 +02:00 · 2025-05-28 23:07:34 +02:00 · 2025-05-28 22:57:18 +02:00 · 2025-05-28 14:49:06 +02:00
4 changed files with 661 additions and 14 deletions
--- a/combined.qmd
+++ b/combined.qmd
@ -0,0 +1,28 @@
+---
+title: "Programmentwurf Advanced SoftwareEngineering"
+subtitle: Für einen [PIC16f84-Simulator (Link)](https://git.paulmartin.cloud/paul/PIC-Simu)
+author:
+    - Luca Müller
+    - Paul Martin 
+date: 05/31/2025
+date-format: "DD.MM.YYYY"
+lang: de
+format:
+    pdf:
+        toc: true
+        number-sections: true
+        colorlinks: true
+crossref:
+    custom:
+      - kind: float
+        reference-prefix: UML-Diagramm
+        key: uml
+        latex-env: uml
+        latex-list-of-description: UML-Diagramme
+---
+
+\newcommand*\listofumlsde{\listof{uml}{Verzeichnis der UML-Diagramme}}
+\listofumlsde
+
+{{< include paul.qmd >}}
+{{< include luca.qmd >}}
--- a/luca.qmd
+++ b/luca.qmd
@ -0,0 +1,510 @@
+---
+lang: de
+format:
+    pdf:
+        toc: true
+        number-sections: true
+        colorlinks: true
+crossref:
+    custom:
+      - kind: float
+        reference-prefix: UML-Diagramm
+        key: uml
+        latex-env: uml
+        latex-list-of-description: UML-Diagramme
+---
+
+# Code Smell 1: Long Method
+
+## Beschreibung des Problems
+
+Das **Long Method** Anti-Pattern tritt auf, wenn eine einzelne Methode zu viele Zeilen Code enthält und multiple Verantwortlichkeiten übernimmt. Eine solche Methode verstößt gegen das **Single Responsibility Principle (SRP)** und führt zu verschiedenen Problemen:
+
+- **Schwere Verständlichkeit**: Entwickler müssen viel Zeit aufwenden, um die gesamte Methode zu durchdringen
+- **Reduzierte Testbarkeit**: Verschiedene Logikbereiche können nicht isoliert getestet werden
+- **Mangelnde Wiederverwendbarkeit**: Teilfunktionalitäten sind nicht separat nutzbar
+- **Erhöhte Fehleranfälligkeit**: Bugs sind schwerer zu lokalisieren und zu beheben
+
+## Praktisches Beispiel
+
+Die folgende Methode `stopRunFromBackend()` zeigt ein typisches Long Method Problem:
+
+### Vorher (Problematischer Code)
+
+```java
+public static void stopRunFromBackend(String message){
+    // Zustandsänderungen
+    isAutoRunActive = false;
+    if (isSleeping)
+        wakeUpFromSleep();
+    else
+        DataRegister.resetPC();
+
+    // UI-Erstellung und -Konfiguration
+    Stage stoppedStage = new Stage();
+    stoppedStage.setTitle("Programm unterbrochen!");
+    VBox vbox = new VBox();
+    vbox.setAlignment(javafx.geometry.Pos.CENTER);
+    Label grundlabel = new Label("Grund: " + message);
+    grundlabel.setStyle("-fx-font-size: 16px; -fx-font-weight: bold;");
+    Label ueberlabel = new Label("Programm unterbrochen!");
+    vbox.getChildren().add(ueberlabel);
+    vbox.getChildren().add(grundlabel);
+    VBox.setMargin(grundlabel, new javafx.geometry.Insets(10, 10, 10, 10));
+    Scene scene = new Scene(vbox, 300, 90);
+    stoppedStage.setAlwaysOnTop(true);
+    stoppedStage.setScene(scene);
+    stoppedStage.show();
+}
+```
+
+### Identifizierte Probleme
+
+- **Vermischte Verantwortlichkeiten**: Die Methode kombiniert Geschäftslogik (Zustandsänderungen) mit UI-Code
+- **Schwere Testbarkeit**: UI-Code kann nicht isoliert von der Geschäftslogik getestet werden
+- **Code-Duplikation**: Wird die Dialog-Funktionalität anderswo benötigt, muss der gesamte UI-Code kopiert werden
+
+## Lösung: Extract Method Refactoring
+
+Die **Extract Method** Technik löst das Problem durch Aufspaltung der langen Methode in kleinere, fokussierte Methoden:
+
+### Nachher (Refactorierter Code)
+
+```java
+public static void stopRunFromBackend(String message){
+    handleExecutionStop();
+    showInterruptionDialog(message);
+}
+
+private static void handleExecutionStop(){
+    isAutoRunActive = false;
+    if (isSleeping)
+        wakeUpFromSleep();
+    else
+        DataRegister.resetPC();
+}
+
+private static void showInterruptionDialog(String message){
+    Stage stoppedStage = new Stage();
+    stoppedStage.setTitle("Programm unterbrochen!");
+
+    VBox vbox = new VBox();
+    vbox.setAlignment(javafx.geometry.Pos.CENTER);
+
+    Label ueberlabel = new Label("Programm unterbrochen!");
+    Label grundlabel = new Label("Grund: " + message);
+    grundlabel.setStyle("-fx-font-size: 16px; -fx-font-weight: bold;");
+
+    vbox.getChildren().addAll(ueberlabel, grundlabel);
+    VBox.setMargin(grundlabel, new javafx.geometry.Insets(10, 10, 10, 10));
+
+    Scene scene = new Scene(vbox, 300, 90);
+    stoppedStage.setAlwaysOnTop(true);
+    stoppedStage.setScene(scene);
+    stoppedStage.show();
+}
+```
+
+## Vorteile der Lösung
+
+- **Klare Trennung der Verantwortlichkeiten**: Geschäftslogik und UI-Code sind getrennt
+- **Verbesserte Lesbarkeit**: Jede Methode hat einen klaren, fokussierten Zweck
+- **Erhöhte Wiederverwendbarkeit**: `showInterruptionDialog()` kann in anderen Kontexten genutzt werden
+- **Bessere Testbarkeit**: Geschäftslogik und UI können separat getestet werden
+
+
+# Code Smell 2: Large Class
+
+## Beschreibung des Problems
+
+Eine **Large Class** entsteht, wenn eine Klasse zu viele Verantwortlichkeiten übernimmt und dadurch überladen wird. Typische Kennzeichen sind:
+
+- **Hohe Anzahl an Instanzvariablen**: Die Klasse verwaltet zu viele verschiedene Datentypen
+- **Viele Methoden**: Unterschiedliche Funktionsbereiche werden in einer Klasse gemischt
+- **Multiple Domänenaspekte**: Logik, Darstellung, Benutzerinteraktion und Statusverwaltung in einer Klasse
+
+## Praktisches Beispiel
+
+Die Klasse `Controller_Frontend` zeigt typische Large Class Probleme:
+
+### Identifizierte Probleme
+
+```java
+public class Controller_Frontend {
+    // GUI-Elemente
+    @FXML private Button startButton;
+    @FXML private Button pauseButton;
+    @FXML private Label statusLabel;
+
+    // Zustandsverwaltung (gehört nicht hierher!)
+    private static boolean isAutoRunActive = false;
+    private static boolean isSleeping = false;
+    private static double executionTimeMultiplier = 1.0;
+
+    // GUI-Steuerung
+    public void handleStart() { /* ... */ }
+    public void handlePause() { /* ... */ }
+
+    // Zustandslogik (gehört nicht hierher!)
+    public void sleep() { isSleeping = true; }
+    public void wakeUpFromSleep() { isSleeping = false; }
+
+    // ... viele weitere Methoden
+}
+```
+
+### Auswirkungen
+
+- **Schwere Wartbarkeit**: Änderungen in einem Bereich können unbeabsichtigte Nebeneffekte verursachen
+- **Reduzierte Testbarkeit**: Verschiedene Aspekte können nicht isoliert getestet werden
+- **Unübersichtlichkeit**: Die Klasse wird schnell unhandlich und schwer verständlich
+- **Violierung des Single Responsibility Principle**: Eine Klasse sollte nur einen Grund zur Änderung haben
+
+## Lösung: Extract Class Refactoring
+
+Die Lösung besteht in der Auslagerung der Zustandsverwaltung in eine separate, spezialisierte Klasse:
+
+### Neue ExecutionState Klasse
+
+```java
+/**
+ * Zentrale Verwaltung aller Ausführungszustände.
+ * Diese Klasse kapselt alle zustandsbezogenen Operationen
+ * und bietet eine saubere API für den Zugriff darauf.
+ */
+public class ExecutionState {
+    private static boolean isAutoRunActive = false;
+    private static boolean isSleeping = false;
+    private static double executionTimeMultiplier = 1.0;
+
+    // AutoRun-Zustand
+    public static boolean isAutoRunActive() {
+        return isAutoRunActive;
+    }
+
+    public static void setAutoRunActive(boolean active) {
+        isAutoRunActive = active;
+    }
+
+    // Sleep-Zustand
+    public static boolean isSleeping() {
+        return isSleeping;
+    }
+
+    public static void sleep() {
+        isSleeping = true;
+    }
+
+    public static void wakeUp() {
+        isSleeping = false;
+    }
+
+    // Ausführungsgeschwindigkeit
+    public static double getExecutionTimeMultiplier() {
+        return executionTimeMultiplier;
+    }
+
+    public static void setExecutionTimeMultiplier(double multiplier) {
+        if (multiplier > 0) {
+            executionTimeMultiplier = multiplier;
+        }
+    }
+
+    // Hilfsmethoden
+    public static void reset() {
+        isAutoRunActive = false;
+        isSleeping = false;
+        executionTimeMultiplier = 1.0;
+    }
+}
+```
+
+### Refactorierte Controller Klasse
+
+```java
+public class Controller_Frontend {
+    // Nur noch GUI-Elemente
+    @FXML private Button startButton;
+    @FXML private Button pauseButton;
+    @FXML private Label statusLabel;
+
+    // Verwendung der ExecutionState Klasse
+    public void stopRunFromBackend(String message) {
+        ExecutionState.setAutoRunActive(false);
+
+        if (ExecutionState.isSleeping()) {
+            ExecutionState.wakeUp();
+        } else {
+            DataRegister.resetPC();
+        }
+
+        showInterruptionDialog(message);
+    }
+
+    // Weitere GUI-Methoden...
+}
+```
+
+## Vorteile der Lösung
+
+- **Klare Verantwortlichkeiten**: Controller fokussiert sich auf GUI, ExecutionState auf Zustandsverwaltung
+- **Verbesserte Testbarkeit**: Zustandslogik kann isoliert getestet werden
+- **Erhöhte Wiederverwendbarkeit**: ExecutionState kann in anderen Klassen genutzt werden
+- **Bessere Wartbarkeit**: Änderungen an der Zustandslogik betreffen nur eine Klasse
+
+
+# Code Smell 3: Shotgun Surgery
+
+## Beschreibung des Problems
+
+**Shotgun Surgery** tritt auf, wenn eine kleine fachliche Änderung Modifikationen an vielen verschiedenen Stellen im Code erfordert. Dieses Anti-Pattern entsteht durch:
+
+- **Zu starke Verteilung**: Zusammengehörige Funktionalität ist über viele Klassen und Methoden verstreut
+- **Mangelnde Kapselung**: Ähnliche Operationen sind nicht zentral gebündelt
+- **Duplizierte Logik**: Gleiche oder ähnliche Code-Fragmente existieren an mehreren Stellen
+
+## Praktisches Beispiel
+
+Die Schlafmodus-Funktionalität war ursprünglich über mehrere Bereiche verteilt:
+
+### Vor dem Refactoring (Problematische Verteilung)
+
+```java
+// In Controller_Frontend
+private boolean isSleeping = false;
+
+public void enterSleepMode() {
+    isSleeping = true;
+    // Logging hier
+    System.out.println("Entering sleep mode");
+}
+
+// In ExecutionEngine
+private boolean sleepState = false;
+
+public void pauseExecution() {
+    sleepState = true;
+    // Ähnliches Logging dort
+    System.out.println("Execution paused - sleep mode");
+}
+
+// In StatusManager
+public void checkSleepStatus() {
+    if (someCondition) {
+        // Wieder ähnlicher Code
+        setSleeping(true);
+        System.out.println("Sleep mode activated");
+    }
+}
+```
+
+### Identifizierte Probleme
+
+- **Mehrfache Implementierung**: Sleep-Logik existiert in verschiedenen Varianten
+- **Inkonsistente Zustände**: Verschiedene Klassen können unterschiedliche Sleep-Zustände haben
+- **Hoher Änderungsaufwand**: Neue Sleep-Features müssen an mehreren Stellen implementiert werden
+- **Fehleranfälligkeit**: Beim Hinzufügen neuer Funktionen können leicht Stellen vergessen werden
+
+## Lösung: Zentralisierung durch Extract Class
+
+Die Lösung besteht in der Konsolidierung aller sleep-bezogenen Operationen in der `ExecutionState` Klasse:
+
+### Zentralisierte Lösung
+
+```java
+public class ExecutionState {
+    private static boolean isSleeping = false;
+    private static final Logger logger = LoggerFactory.getLogger(ExecutionState.class);
+
+    /**
+     * Aktiviert den Schlafmodus mit einheitlichem Logging und Zustandsmanagement
+     */
+    public static void sleep() {
+        if (!isSleeping) {
+            isSleeping = true;
+            logger.info("Sleep mode activated");
+            notifyStateChange("SLEEP_ACTIVATED");
+        }
+    }
+
+    /**
+     * Deaktiviert den Schlafmodus
+     */
+    public static void wakeUp() {
+        if (isSleeping) {
+            isSleeping = false;
+            logger.info("Waking up from sleep mode");
+            notifyStateChange("SLEEP_DEACTIVATED");
+        }
+    }
+
+    /**
+     * Überprüft den aktuellen Schlafzustand
+     */
+    public static boolean isSleeping() {
+        return isSleeping;
+    }
+
+    /**
+     * Erweiterte Sleep-Funktionalität mit Timeout
+     */
+    public static void sleepWithTimeout(long milliseconds) {
+        sleep();
+        Timer timer = new Timer();
+        timer.schedule(new TimerTask() {
+            @Override
+            public void run() {
+                wakeUp();
+            }
+        }, milliseconds);
+    }
+
+    private static void notifyStateChange(String event) {
+        // Zentrale Benachrichtigung für alle interessierten Komponenten
+        EventBus.getInstance().publish(new StateChangeEvent(event));
+    }
+}
+```
+
+### Vereinfachte Nutzung in anderen Klassen
+
+```java
+// In Controller_Frontend
+public void handleSleepButton() {
+    ExecutionState.sleep();
+    updateUI();
+}
+
+// In ExecutionEngine
+public void pauseIfNeeded() {
+    if (shouldPause()) {
+        ExecutionState.sleep();
+    }
+}
+
+// In StatusManager
+public void checkAndActivateSleep() {
+    if (criticalCondition()) {
+        ExecutionState.sleepWithTimeout(5000); // 5 Sekunden Sleep
+    }
+}
+```
+
+## Vorteile der Lösung
+
+- **Einheitliche Implementierung**: Alle sleep-bezogenen Operationen verwenden dieselbe Logik
+- **Zentrale Wartung**: Änderungen müssen nur an einer Stelle vorgenommen werden
+- **Konsistente Zustände**: Nur eine Quelle der Wahrheit für den Sleep-Zustand
+- **Erweiterte Funktionalität**: Neue Features (wie Timeout) können zentral hinzugefügt werden
+- **Bessere Nachverfolgbarkeit**: Einheitliches Logging und Event-System
+
+# Anwendung von Programmierprinzipien im Projekt
+
+## Einleitung
+Im Rahmen der Refaktorisierung und Weiterentwicklung des Projekts wurde besonderer Fokus auf die Einhaltung zentraler Programmierprinzipien gelegt. Die folgenden Prinzipien wurden gezielt analysiert und angewendet:
+
+## 1. SOLID-Prinzipien
+
+### Single Responsibility Principle (SRP)
+Die Methode `stopRunFromBackend()` wurde in zwei unabhängige Methoden aufgeteilt:
+
+```java
+public void stopRunFromBackend(String message) {
+    ExecutionState.setAutoRunActive(false);
+    handleSleepOrReset();
+    showStopDialog(message);
+}
+
+private void handleSleepOrReset() {
+    if (ExecutionState.isSleeping()) {
+        ExecutionState.wakeUp();
+    } else {
+        dataRegister.resetPC();
+    }
+}
+
+private static void showStopDialog(String message) {
+    // GUI-Erzeugung...
+}
+```
+
+### Open/Closed Principle (OCP)
+Die Klasse `ExecutionState` kapselt erweiterbare Zustandslogik, ohne dass bestehende Methoden geändert werden müssen:
+
+```java
+public class ExecutionState {
+    private static boolean isAutoRunActive;
+    private static boolean isSleeping;
+
+    public static boolean isSleeping() { return isSleeping; }
+    public static void wakeUp() { isSleeping = false; }
+    public static void setAutoRunActive(boolean value) {
+        isAutoRunActive = value;
+    }
+}
+```
+
+### Liskov Substitution Principle (LSP)
+`Controller_Frontend` implementiert ein Interface, wodurch die Substituierbarkeit gemäß LSP gewährleistet ist:
+
+```java
+public class Controller_Frontend extends PICComponent implements FrontendControllerInterface { }
+
+public void resetPC() {
+    programCounter = 0;
+}
+```
+
+### Interface Segregation Principle (ISP)
+Spezialisierte Interfaces sorgen dafür, dass Klassen nur relevante Funktionen implementieren:
+
+```java
+public interface TimerInterface {
+    void start();
+    void stop();
+    int getCurrentTime();
+}
+```
+
+### Dependency Inversion Principle (DIP)
+Zentrale Komponenten wie `PICComponentLocator` und Interfaces lösen die Abhängigkeit von konkreten Klassen:
+
+```java
+private PICComponentLocator picComponents;
+```
+
+## 2. GRASP-Prinzipien
+
+### Low Coupling
+Die Kopplung im Projekt ist durch Verwendung zentraler Zugriffsklassen wie `PICComponentLocator` gering gehalten.
+
+```java
+private PICComponentLocator picComponents;
+```
+
+### High Cohesion
+Funktionen übernehmen jeweils thematisch zusammenhängende Aufgaben:
+
+```java
+public static void showStopDialog(String message) {
+    Stage stoppedStage = new Stage();
+    VBox vbox = new VBox();
+    Label grundlabel = new Label("Grund: " + message);
+    // GUI-Details ausgelassen
+    stoppedStage.show();
+}
+```
+
+## 3. DRY – Don’t Repeat Yourself
+Wiederverwendbare Logik zur Statuskontrolle wurde in `ExecutionState` gekapselt. GUI-Erzeugung findet zentral in `showStopDialog()` statt:
+
+```java
+public class ExecutionState {
+    private static boolean isSleeping;
+    public static boolean isSleeping() { return isSleeping; }
+    public static void wakeUp() { isSleeping = false; }
+}
+
+private static void showStopDialog(String message) {
+    // einmal zentral definierte GUI-Logik
+}
--- a/paul.qmd
+++ b/paul.qmd
@ -0,0 +1,123 @@
+---
+lang: de
+format:
+    pdf:
+        toc: true
+        number-sections: true
+        colorlinks: true
+crossref:
+    custom:
+      - kind: float
+        reference-prefix: UML-Diagramm
+        key: uml
+        latex-env: uml
+        latex-list-of-description: UML-Diagramme
+---
+
+{{< pagebreak >}}
+
+# Entwurfsmuster
+Zusätzlich zu den beiden im Folgenden dargestellten Entwursmustern benutzen wir einen [Service Locator](https://en.wikipedia.org/wiki/Service_locator_pattern), der zu den [Architectural Patterns](https://en.wikipedia.org/wiki/Architectural_pattern) zählt. Dieses Pattern nutzt ein `HashMap`, in der verschiedene Komponenten des Programms gespeichert werden, um das Komponenten-Management zu vereinfachen und explizite Abhängigkeiten der Komponenten untereinander zu vermeiden, die das Initialisieren der einzelnen Komponenten erschweren könnten. 
+In unserem Projekt fungiert [`PICComponentLocator`] als dieser Locator. Er besitzt einen `componentCatalogue` als Member, der eine `Map<Class<? extends PICComponentInterface>, PICComponentInterface>` ist. Das bedeutet, dass alle Klassen, die durch den Locator gemanaget werden sollen, das `PICComponentInterface` implementieren müssen. Dieses ist wie folgt [definiert]: 
+```java
+public interface PICComponentInterface {
+    void initialize(PICComponentLocator picComponents);
+}
+```
+Um nicht bei allen Zugriffen die `PICComponentLocator.getComponent()` ausführen zu müssen, wurde zusätzlich die `abstract` Klasse `PICComponent` [eingeführt]. Sie besitzt als Member alle implementierten Komponenten, also sollten neue Komponenten ebenfalls das Interface implementieren und als Member in `PICComponent` angelegt werden. Alle Komponenten können diese Klasse `extend`en und dadurch auch alle weiteren Komponenten als Member haben. Durch die `initialize`-Funktion des `PICComponent` werden durch einen Aufruf der `PICComponentLocator.initAll()` alle Member vom Locator geholt. 
+
+## Marker-Entwurfsmuster
+[Marker-Patterns](https://en.wikipedia.org/wiki/Marker_interface_pattern) werden allgemein genutzt, um Klassen Metadaten zuzuordnen. In unserem Projekt stellen die `FrontendSpecific`-Interfaces Marker dar, die genutzt werden um zu kommunizieren, dass Klassen andere Klassen benötigen, die Frontend-spezifisch sind und somit besonders beachtet werden müssen. So können alle [`Interface`s](LINK ZU ORDNER) definiert werden ohne direkt von fremdem Code abhängig zu sein. Bei möglichen anderen Frontend-Implementierungen müssten entsprechend nur die passenden Klassen die jeweiligen Interfaces implementieren und nichts an den Interfaces ändern.
+Eingeführt wurden die `FrontendSpecific`s in [Commit 06e9348016](https://git.paulmartin.cloud/paul/PIC-Simu/commit/06e934801645e32dea5415ccb4f38368a1667df6) ([hier](https://git.paulmartin.cloud/paul/PIC-Simu/commit/ef3b0fce5f9b6cce06494ff6ce59f5534064e7d2) verfollständigt). Es wurde zunächst ein `FrontendSpecificObject`-Interface angelegt, das alle Frontend-spezifischen Klassen beschreibt, die von Methoden anderer Klassen genutzt werden (sprich, die in den  [`Interface`s](LINK ZU ORDNER) vorkommen). Es ist - entsprechend des Marker-Patterns - komplett leer [definiert](src/main/java/fabrik/simulator/pic16f84/frontendspecifics/FrontendSpecificObject.java):
+```java
+public interface FrontendSpecificObject { 
+}
+```
+Zusätzlich gibt es für spezifische Frontend-Klassen auch `FrontendSpecific`-Interfaces, sodass nach wie vor nur bestimmte Klassen über- bzw. zurückgegeben werden können. Diese spezifischen Interfaces sind ebenfalls leer, nur nutzen sie `extends FrontendSpecificObject` um zu verdeutlichen, dass sie zu den allgemeinen `FrontendSpecificObject`s gehören. Hier beispielsweise [`FrontendSpecificCircle`](src/main/java/fabrik/simulator/pic16f84/frontendspecifics/FrontendSpecificCircle.java):
+```java
+public interface FrontendSpecificCircle extends FrontendSpecificObject {
+}
+```
+Tatsächlich genutzt werden die `FrontendSpecific`-Interfaces von [Circle], [ToggleButtonGroup] und [Vbox]. Sie `extenden` ihr jeweiliges `JavaFX`-Pendant und `implementen` ihr jeweiliges `FrontendSpecific`-Interface. Darüber hinaus implementieren sie nur die nötigen (also im Code tatsächlich genutzten) Konstruktoren, die wiederum nur `super()` aufrufen, hier bspw. [`ToggleButtonGroup`]:
+```java
+public class ToggleButtonGroup extends 
+              com.gluonhq.charm.glisten.control.ToggleButtonGroup 
+                implements FrontendSpecificToggleButtonGroup {
+    public ToggleButtonGroup(){
+        super();
+    }
+
+    public ToggleButtonGroup(ToggleButton... toggles) {
+        super(toggles);
+    }    
+}
+```
+Alle für das Marker-Pattern eingeführten Klassen sind in @uml-marker erkennbar:
+
+::: {#uml-marker}
+
+```{mermaid}
+%%| fig-width: 6.5
+classDiagram
+direction TB
+class FrontendSpecificObject {
+    <<interface>>
+}
+class FrontendSpecificToggleButtonGroup {
+    <<interface>>
+}
+class ToggleButtonGroup {
+    public ToggleButtonGroup()
+    public ToggleButtonGroup(ToggleButton... toggles)
+}
+
+class `com.gluonhq.charm.glisten.control.ToggleButtonGroup` {
+    ...
+    ....()
+}
+
+FrontendSpecificObject <|-- FrontendSpecificToggleButtonGroup : << extends >>
+FrontendSpecificToggleButtonGroup <|-- ToggleButtonGroup : << implements >>
+`com.gluonhq.charm.glisten.control.ToggleButtonGroup` <|-- ToggleButtonGroup : << extends >>
+
+class FrontendSpecificVBox{
+    <<interface>>
+}
+class VBox {
+    public VBox()
+}
+
+class `javafx.scene.layout.VBox` {
+    ...
+    ....()
+}
+
+FrontendSpecificObject <|-- FrontendSpecificVBox : << extends >>
+FrontendSpecificVBox <|-- VBox : << implements >>
+`javafx.scene.layout.VBox` <|-- VBox : << extends >>
+
+class FrontendSpecificCircle {
+    <<interface>>
+}
+class Circle {
+    public Circle()
+}
+
+class `javafx.scene.shape.Circle` {
+    ...
+    ....()
+}
+
+
+FrontendSpecificObject <|-- FrontendSpecificCircle : << extends >>
+FrontendSpecificCircle <|-- Circle : << implements >>
+`javafx.scene.shape.Circle` <|-- Circle : << extends >>
+
+
+```
+
+Das genutzte Marker-Pattern und alle seine Verwendungen
+:::
+## Beobachter- (/Observer-) Entwurfsmuster
+[Beobachter-Entwurfsmuster](https://en.wikipedia.org/wiki/Observer_pattern) werden genutzt, damit ein Subjekt mehrere Beobachter über eine Zustandsänderung informieren kann. In unserem Projekt passiert das bei einer Änderung der `totalExecutionTime`. Das Subjekt `ExecutionTimeSubject` führt hierbei ein `Set` an Beobachtern, die bei uns durch das Interface `ExecutionTimeObserver` repräsentiert werden, welches durch die `registerObserver`- und `unregisterObserver`-Funktionen verwaltet werden kann. Bei einer Zustandsänderung muss die `notifyObservers`-Funktion aufgerufen werden, welche für alle Observer die im Interface spezifizierte `executionTimeChanged`-Funktion aufruft. 
+
--- a/template.qmd
+++ b/template.qmd
@ -1,14 +0,0 @@
---
-title: "Programmentwurf AdvancedSoftwareEngineering"
-author:
-    - Luca Müller
-    - Paul Martin 
-date: 05/31/2025
-date-format: "DD.MM.YYYY"
-lang: de
-format:
-  pdf:
-    toc: true
-    number-sections: true
-    colorlinks: true
---
Author	SHA1	Message	Date
Paul Martin	68d7f3c3d9	Combined Draft 1	2025-05-28 23:21:48 +02:00
Paul Martin	ce8a77d049	Merge luca into advancedSE	2025-05-28 23:07:34 +02:00
Paul Martin	4f219ad5d5	Draft 1 docu	2025-05-28 22:57:18 +02:00
LucaaMueller	d56c7a1439	quarto datei mit refactoring und programm principles	2025-05-28 14:49:06 +02:00