317 lines
14 KiB
Plaintext
317 lines
14 KiB
Plaintext
---
|
||
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<Class<? extends PICComponentInterface>, 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 {
|
||
<<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 >>
|
||
|
||
class PICComponentInterface{
|
||
<<Interface>>
|
||
+ initialize(PICComponentLocator picComponents)
|
||
}
|
||
|
||
class WindowManagement{
|
||
<<Interface>>
|
||
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{
|
||
<<Interface>>
|
||
+ initialize(PICComponentLocator picComponents)
|
||
}
|
||
|
||
|
||
class CommandInterface {
|
||
<<Interface>>
|
||
+ CALL(int isr);
|
||
|
||
+ get_wRegister();
|
||
|
||
+ decode(int i);
|
||
}
|
||
|
||
|
||
class PICComponent{
|
||
<<Abstract>>
|
||
# DataRegisterInterface dataRegister
|
||
...
|
||
|
||
+ initialize(PICComponentLocator locator)
|
||
}
|
||
|
||
|
||
class ExecutionTimeSubject{
|
||
<<Abstract>>
|
||
- Set~ExecutionTimeObserver~ observers
|
||
|
||
+ registerObserver(ExecutionTimeObserver observer)
|
||
+ unregisterObserver(ExecutionTimeObserver observer)
|
||
+ getTotalExecutionTime()
|
||
+ addExecutionTime(int i)
|
||
+ getExecutionTimeMultiplier()
|
||
# notifyObservers()
|
||
....()
|
||
}
|
||
|
||
|
||
class Commands{
|
||
- wRegister
|
||
- totalExecutionTime
|
||
- executionTimeMultiplier
|
||
....()
|
||
}
|
||
|
||
class FrontendSpecificObject {
|
||
<<Interface>>
|
||
}
|
||
|
||
class FrontendControllerInterface{
|
||
<<Interface>>
|
||
+ getPORTbuttons() FrontendSpecificToggleButtonGroup[]
|
||
+ getTRISbuttons() FrontendSpecificToggleButtonGroup[]
|
||
+ stopRunFromBackend(String watchdogTimer)
|
||
}
|
||
|
||
|
||
class Controller_Frontend {
|
||
...
|
||
....()
|
||
}
|
||
|
||
class TimerInterface {
|
||
<<Interface>>
|
||
+ cycles(int i)
|
||
+ incrementFromPin(int directRegister)
|
||
+ increment(boolean manual)
|
||
}
|
||
|
||
class Timer {
|
||
...
|
||
....()
|
||
}
|
||
|
||
|
||
class EEPROMInterface {
|
||
<<Interface>>
|
||
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 {
|
||
<<Interface>>
|
||
+ 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
|
||
``` |