--- 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`](https://git.paulmartin.cloud/paul/PIC-Simu/src/commit/c38835fd7b47c662a344c9ab2c41e0527760bd61/src/main/java/fabrik/simulator/pic16f84/PICComponentLocator.java) als dieser Locator. Er besitzt einen `componentCatalogue` als Member, der eine `Map, PICComponentInterface>` ist. Das bedeutet, dass alle Klassen, die durch den Locator gemanaget werden sollen, das `PICComponentInterface` implementieren müssen. 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, dies ist auch in @uml-observer dargestellt [^1]. 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 [diesem Commit](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](https://git.paulmartin.cloud/paul/PIC-Simu/src/commit/f28603843d7ef6cbf4666ab2b2ceda02ca411eb7/src/main/java/fabrik/simulator/pic16f84/interfaces) vorkommen). Es ist - entsprechend des Marker-Patterns - komplett leer [definiert](https://git.paulmartin.cloud/paul/PIC-Simu/src/commit/f28603843d7ef6cbf4666ab2b2ceda02ca411eb7/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`](https://git.paulmartin.cloud/paul/PIC-Simu/src/commit/ef3b0fce5f9b6cce06494ff6ce59f5534064e7d2/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 [^1]: ::: {#uml-marker} ```{mermaid} %%| fig-width: 6.5 classDiagram direction TB class FrontendSpecificObject { <> } class FrontendSpecificToggleButtonGroup { <> } 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{ <> } class VBox { public VBox() } class `javafx.scene.layout.VBox` { ... ....() } FrontendSpecificObject <|-- FrontendSpecificVBox : << extends >> FrontendSpecificVBox <|-- VBox : << implements >> `javafx.scene.layout.VBox` <|-- VBox : << extends >> class FrontendSpecificCircle { <> } class Circle { public Circle() } class `javafx.scene.shape.Circle` { ... ....() } FrontendSpecificObject <|-- FrontendSpecificCircle : << extends >> FrontendSpecificCircle <|-- Circle : << implements >> `javafx.scene.shape.Circle` <|-- Circle : << extends >> class PICComponentInterface{ <> + initialize(PICComponentLocator picComponents) } class WindowManagement{ <> refreshTable()$ startFromMain(String[] args)$ } FrontendSpecificObject <|-- WindowManagement : << extends >> PICComponentInterface <|-- WindowManagement : << 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. Die Implementierung wurde [hier](https://git.paulmartin.cloud/paul/PIC-Simu/commit/85bc6e9ebae4655ba3ad7ee360332010edc910dd) begonnen, [hier](https://git.paulmartin.cloud/paul/PIC-Simu/commit/cf6bcd8498cd2d03e85b0c5f6faaaed935d3a155) vereinfacht um das Threading des Frontends zu respektieren und [hier](https://git.paulmartin.cloud/paul/PIC-Simu/commit/52d63523341179c3c49e0ac31a60a8d7c11cdddc) in die letzten Tests eingefügt. In der aktuellen Umsetzung übernimmt die [`Commands`](https://git.paulmartin.cloud/paul/PIC-Simu/src/commit/ef3b0fce5f9b6cce06494ff6ce59f5534064e7d2/src/main/java/fabrik/simulator/pic16f84/Commands.java)-Klasse gleichzeitig die Rolle des `ExecutionTimeSubject`s und `CommandsInterface`s. Deshalb [wird in der `Main`-Klasse](https://git.paulmartin.cloud/paul/PIC-Simu/src/commit/85bc6e9ebae4655ba3ad7ee360332010edc910dd/src/main/java/fabrik/simulator/pic16f84/Main.java) das `Commands`-Objekt dem `ComponentLocator` sowohl für die `ExecutionTimeSubject.class` als auch für die `CommandInterface.class` hinzugefügt. `ExecutionTimeObserver` sind die Klassen, die vorher `commands.getTotalExecutionTime()` gepollt haben. Die Implementierung dieses Entwursmusters ist in @uml-observer erkennbar [^1]: :::{#uml-observer} ```{mermaid} %%| fig-width: 6.5 classDiagram direction TB class PICComponentInterface{ <> + initialize(PICComponentLocator picComponents) } class CommandInterface { <> + CALL(int isr); + get_wRegister(); + decode(int i); } class PICComponent{ <> # DataRegisterInterface dataRegister ... + initialize(PICComponentLocator locator) } class ExecutionTimeSubject{ <> - Set~ExecutionTimeObserver~ observers + registerObserver(ExecutionTimeObserver observer) + unregisterObserver(ExecutionTimeObserver observer) + getTotalExecutionTime() + addExecutionTime(int i) + getExecutionTimeMultiplier() # notifyObservers() ....() } class Commands{ - wRegister - totalExecutionTime - executionTimeMultiplier ....() } class FrontendSpecificObject { <> } class FrontendControllerInterface{ <> + getPORTbuttons() FrontendSpecificToggleButtonGroup[] + getTRISbuttons() FrontendSpecificToggleButtonGroup[] + stopRunFromBackend(String watchdogTimer) } class Controller_Frontend { ... ....() } class TimerInterface { <> + cycles(int i) + incrementFromPin(int directRegister) + increment(boolean manual) } class Timer { ... ....() } class EEPROMInterface { <> registerTime(double executionTime, boolean b) parse(int i, int content, int i1) read(int address) long write(int address, long data) } class EEPROM { ... ....() } class ExecutionTimeObserver { <> + executionTimeChanged() } ExecutionTimeObserver <|-- Timer : << implements >> TimerInterface <|-- Timer : << implements >> PICComponent <|-- Timer : << extends >> PICComponentInterface <|-- TimerInterface : << extends >> PICComponentInterface <|-- EEPROMInterface : << extends >> ExecutionTimeObserver <|-- EEPROM : << implements >> EEPROMInterface <|-- EEPROM : << implements >> PICComponent <|-- EEPROM : << extends >> ExecutionTimeObserver <|-- Controller_Frontend : << implements >> PICComponent <|-- Controller_Frontend : << extends >> PICComponentInterface <|-- PICComponent : << implements >> PICComponentInterface <|-- FrontendControllerInterface : << extends >> FrontendControllerInterface <|-- Controller_Frontend : << implements >> FrontendSpecificObject <|-- FrontendControllerInterface : << extends >> CommandInterface <|-- Commands : << implements >> ExecutionTimeSubject <|-- Commands : << extends >> PICComponent <|-- ExecutionTimeSubject : << extends >> PICComponentInterface <|-- CommandInterface : << extends >> ``` Das genutzte Observer-Pattern und seine Verwendungen im (Nicht-Test-) Code. ::: [^1]: Für das Pattern unwichtige Funktionen und Variablen wurden ausgelassen # Clean Architecture Die Clean Architecture ist darauf ausgelegt, Softwareprojekte langfristig betreibbar, flexibel und wartbar zu halten. Dazu wird das Projekt in **konzentrische Schichten** unterteilt, in denen die **Abhängigkeitsrichtung stets von außen nach innen** verläuft – die sogenannte *Dependency Rule*. Der Kern der Anwendung bleibt dabei vollständig unabhängig von technischen Details wie Benutzeroberflächen, Datenbanken oder Netzwerken. In unserem Projekt haben wir diese Schichtarchitektur wie folgt umgesetzt: ## 1. Interface/Adapter-Schicht Diese Schicht enthält alle Klassen, die als Schnittstelle zwischen der Anwendung und der Benutzeroberfläche dienen. Dazu zählen alle Klassen im Package, `fabrik.simulator.pic16f84.frontendspecifics` insbesondere: - `Controller_Frontend` - `CreateWindow` - `IOPorts` - `ToggleButtonGroupExt` Diese Klassen erben vom `FrontendSpecificObject` und sind spezifisch für die grafische Oberfläche. Sie implementieren die Schnittstellen der inneren Schichten und leiten Benutzerinteraktionen weiter. ## 2. Application Code Die nächstinnere Schicht beinhaltet die anwendungsspezifische Logik – unsere *Use Cases*. Dazu zählen sämtliche Klassen im Package `fabrik.simulator.pic16f84`, **sofern sie nicht vom `FrontendSpecificObject` erben**. Diese Schicht ist weitgehend unabhängig von der GUI und bleibt stabil, selbst wenn sich die Darstellung oder Eingabeform ändert. Diese Klassen gehören zur Anwendungslogik: - `Timer` - `PreScaler` - `WatchdogTimer` - `ProgrammStack` ## Main-Klasse als Plugin Die `Main`-Klasse bildet den äußeren Rahmen (Plugin-Schicht) und initialisiert die gesamte Anwendung: - Es werden alle Objekte erzeugt und dem `Locator` zugewiesen. - Das `WindowManagement` startet das Frontend. Ein besonders interessanter Aspekt: Wenn man sämtliche Referenzen auf das Frontend (z. B. in Zeile 19, 20, 23) entfernt, lässt sich die App **trotzdem erfolgreich starten und nutzen**. Das zeigt, dass die Schichten entkoppelt sind – ein zentrales Ziel der Clean Architecture. \newpage ## Visualisierung ```{mermaid} flowchart TB subgraph Interface/Adapter-Schicht A1[Controller_Frontend, CreateWindow, IOPorts, ToggleButtonGroupExt] end subgraph Application Code A2[Use Cases, WatchdogTimer, PreScaler, ProgrammStack, Timer] end subgraph Plugin-Schicht A3[Main.java] end A3 --> A1 A1 --> A2 ```