update
This commit is contained in:
David Schirrmeister
86
Writerside/topics/02/OOAD/AgileDesign.md
Normal file
86
Writerside/topics/02/OOAD/AgileDesign.md
Normal file
@ -0,0 +1,86 @@
|
||||
# Agile Design
|
||||
> [UML](UML.md) ist nicht Software Design
|
||||
|
||||
- Diagramme repräsentieren einen Teil des SW-Designs
|
||||
- Source Code
|
||||
- Design ist ein abstraktes Konzept
|
||||
- Struktur und Form des Projekts
|
||||
- Detaillierte Beschreibung der Klassen, Module, Methoden
|
||||
|
||||
|
||||
## What goes wrong with Software
|
||||
- Im besten Fall
|
||||
- Projekt startet mit klarem Bild, was das System tun soll
|
||||
- Design ist ein Bild in den Köpfen der Devs
|
||||
- Mit Glück: Klarheit des Designs schafft es bis zum ersten Release
|
||||
- Häufig geht vorher was schief
|
||||
- Programm wird schwieriger wartbar
|
||||
- kleinste Änderungen werden kompliziert
|
||||
- Neudesign geht meistens schief
|
||||
- Das alte System wächst weiter, neues muss mithalten
|
||||
- Probleme im neuen Design entstehen
|
||||
- Software geht kaputt, wenn es anfängt mit Design Smells:
|
||||
|
||||
## Design Smells
|
||||
### Rigidity (Steifigkeit)
|
||||
- Das Design ist schwer zu ändern
|
||||
- Code ist schwer zu ändern
|
||||
- kleine Änderungen erzeugen Probleme in dependent Modulen
|
||||
- je mehr Module geändert werden müssen, desto mehr steif ist das Design
|
||||
- Ergebnis:
|
||||
- Änderungen dauern deutlich länger als gedacht
|
||||
|
||||
### Fragility (Zerbrechlichkeit)
|
||||
- Das Design ist einfach kaputtzumachen
|
||||
- Neue Probleme sind in unvorhergesehenen Umgebungen
|
||||
- Lösen dieser Probleme führt zu neuen Problemen
|
||||
- Fragilität wird mit der Zeit höher
|
||||
- Ist sehr normal
|
||||
- Module sind bekannt dafür, dass sie repariert werden müssen
|
||||
- Sind auf der Bug Liste
|
||||
- Niemand will sich der Aufgabe widmen
|
||||
|
||||
### Immobility
|
||||
- Das Design ist kaum neu zu benutzen
|
||||
- Enthält Teile, die in anderen Systemen sinnvoll wären
|
||||
- Risiko involviert in Aufteilung
|
||||
- Ungünstig, aber sehr häufig
|
||||
|
||||
### Viscosity
|
||||
- Es ist schwer das Richtige zu tun. Zwei Formen:
|
||||
1. Viskosität der Software
|
||||
- Devs entscheiden zwischen Designerhaltung und einfacher Lösung
|
||||
- Design sollte design erhaltende Änderungen fördern
|
||||
2. Viskosität der Umgebung
|
||||
- Umgebungen, die einfache statt design erhaltende Änderungen
|
||||
- Lange compile Zeiten verringern Lust auf recompilen
|
||||
- Lange VCS-Check-ins verringern Check-ins
|
||||
|
||||
### Needless Complexity
|
||||
- Ein Design enthält Elemente, die momentan nicht nützlich sind
|
||||
- Passiert häufig, wenn Devs Änderungen erwarten
|
||||
- Vorbereitung für zukünftigen Code
|
||||
- Das Design muss das Gewicht dieser Elemente nun mittragen
|
||||
- Manche Vorbereitungen sind nützlich, aber nicht alle
|
||||
- Software wird komplex
|
||||
|
||||
### Needless Repetition
|
||||
- Copy Paste sollte nicht benutzt werden
|
||||
- Wenn Code mehrfach in minimal unterschiedlichen Formen vorkommt
|
||||
- Devs haben Abstraktion vergessen
|
||||
- Wiederholungen sollten gefunden und beseitigt werden
|
||||
- Wiederholender Code macht Änderungen schwierig
|
||||
- Bugs müssen in allen Wiederholungen geändert werden
|
||||
- Änderungen nicht immer gleich in allen
|
||||
|
||||
|
||||
### Opacity
|
||||
- Code ist in einer unverständlichen Art geschrieben
|
||||
- Häufig in Code der über Zeit weiterentwickelt wird
|
||||
- Benötigt konstanten Einsatz den Code clean zu halten
|
||||
- Wenn Code das erste Mal geschrieben wird, scheint er clean
|
||||
- Verständnis auf intimer Ebene
|
||||
- Devs müssen aus der Sicht eines Außenstehenden gucken
|
||||
- Refactor bis Leser es verstehen können
|
||||
- Code von anderen lesen lassen
|
||||
|
||||
277
Writerside/topics/02/OOAD/DesignPatterns.md
Normal file
277
Writerside/topics/02/OOAD/DesignPatterns.md
Normal file
@ -0,0 +1,277 @@
|
||||
# Design Patterns
|
||||
- Typische Lösung für häufige Probleme im Software Design
|
||||
- Kein Code, nur Lösungsansatz
|
||||
- Gute OO-Designs sind wiederverwendbar, erweiterbar, wartbar
|
||||
|
||||
## Pattern - SOLID
|
||||
|
||||
| | Factory | Singleton | Composite | Adapter | Facade | Observer | Strategy | State |
|
||||
|-----------------------------------------------------------------|---------------------------------------------------------------|-----------|---------------------------|--------------------------------|-----------------------------|----------|----------|-------|
|
||||
| [Srp](SOLID-Principle.md#s-single-responsibility-principle-srp) | X <br/>viele unterschiedliche Creator, die eine Aufgabe haben | - | ? <br/>(sowohl als auch) | x | X<br/>mit Tendenz zu ? | X | | |
|
||||
| [Ocp](SOLID-Principle.md#o-open-closed-principle-ocp) | X | - | X | x | - <br/>zumindest in Vorlage | X | | |
|
||||
| [Lsp](SOLID-Principle.md#l-liskov-s-substitution-principle-lsp) | ? | - | ? <br/>(kann, muss nicht) | - | - | X | | |
|
||||
| [Isp](SOLID-Principle.md#i-interface-segregation-principle-isp) | ?/X | - | - | X<br/>sollte, kann aber auch ? | - <br/>zumindest in Vorlage | X | | |
|
||||
| [Dip](SOLID-Principle.md#d-dependency-inversion-principle-dip) | X | - | X | X | - <br/>zumindest in Vorlage | ? | | |
|
||||
|
||||
### Legend
|
||||
- **X**: follows clearly
|
||||
- **?**: not sure, might follow / changes with implementation
|
||||
- **-**: has nothing to do with it
|
||||
|
||||
## Typen von Design Patterns
|
||||
- **Creational Patterns**
|
||||
- Objekterstellungsmechanismen → erhöhen Flexibilität
|
||||
- **Strukturelle Pattern**
|
||||
- Objekte anwenden und Klassen in größeren Strukturen gruppieren ohne Flexibilität einzubußen
|
||||
- **Behavioral Patterns**
|
||||
- Algorithmen und Zuordnung von Verantwortlichkeiten
|
||||
|
||||
## How to use a design pattern
|
||||
- Bibliotheken
|
||||
|
||||
## Observer Pattern
|
||||
- One-To-Many Abhängigkeit
|
||||
- Wenn ein Objekt sich ändert
|
||||
- Alle Abhängigkeiten werden benachrichtigt
|
||||
|
||||
### Nutzung Observer Pattern
|
||||
- Wenn Zustandsänderung eines Objekts Änderung in anderen Objekten hervorruft
|
||||
- Wenn Objekte etwas beobachten müssen für eine bestimmte Zeit/Fall
|
||||
|
||||
### Beispiel Observer Pattern
|
||||
- Kunden über Verfügbarkeit von Produkten informieren
|
||||
- 2 Typen von Objekten: Kunde, Markt
|
||||
|
||||
#### Pull
|
||||
- Kunde fragt häufiger nach, ob es da ist
|
||||
- Meistens: NEIN
|
||||
|
||||
#### Push
|
||||
- Markt schreibt alle Kunden an, sobald ein Produkt verfügbar ist
|
||||
- Auch die, die kein Interesse haben
|
||||
|
||||
#### Observer
|
||||
- Jedes Produkt hat eine Liste von Subscribern
|
||||
- Sobald sich Verfügbarkeit ändert alle benachrichtigen
|
||||
|
||||
### Struktur Observer Pattern
|
||||
|
||||
#### Subject (Interface)
|
||||
- Kennt seine Beobachter
|
||||
|
||||
#### Observer (Interface)
|
||||
- Definiert Interface für Objekte, welche benachrichtigt werden sollen
|
||||
|
||||
#### ConcreteSubject
|
||||
- Speichert Daten (oder Zustand) der Interesse
|
||||
- Sendet Benachrichtigung bei Änderung
|
||||
|
||||
#### Concrete Observer
|
||||
- Behält Referenz zu ConcreteSubject
|
||||
- Gespeicherter Zustand bleibt gleich mit Subject-Zustand
|
||||
- Implementiert das update-Interface des Observers
|
||||
|
||||
### Fazit Observer Pattern
|
||||
- Wird gefördert durch das [OPC](SOLID-Principle.md#o-open-closed-principle-ocp)
|
||||
- [LSP](SOLID-Principle.md#l-liskov-s-substitution-principle-lsp) wird angewendet
|
||||
- [DIP](SOLID-Principle.md#d-dependency-inversion-principle-dip) wird angewendet
|
||||
- [ISP](SOLID-Principle.md#i-interface-segregation-principle-isp) wird manchmal angewendet
|
||||
- Manchmal kann eine Klasse Observer und Subjekt sein
|
||||
|
||||
|
||||
## Factory Method (Virtual Constructor)
|
||||
- Interface für die Erstellung eines Objekts
|
||||
- Lässt Subklassen entscheiden welche Klassen instanziiert wird
|
||||
- Ersteller Klassen wissen nicht von den tatsächlichen Objekten
|
||||
|
||||
### Struktur Factory Method
|
||||
|
||||
#### Product (Abstract Class / Interface)
|
||||
- Definiert üblichen Typ der Objekte
|
||||
- Abstraktion, welche von der restlichen Codebase genutzt wird
|
||||
|
||||
#### Concrete Product(s)
|
||||
- Implementierung des Produkt-Interface
|
||||
|
||||
#### Creator (Abstract Class)
|
||||
- Deklariert Factory-Methode
|
||||
- Gibt Objekt zurück
|
||||
- Kann noch andere Methoden enthalten
|
||||
|
||||
#### ConcreteCreator
|
||||
- Jedes semantische Produkt hat seinen eigenen ConcreteCreator
|
||||
- Überschreiben der Factory-Methode
|
||||
- Implementierung der Kreation der spezifischen Produkte
|
||||
- Mehrere ConcreteCreator können ein ConcreteProduct erstellen (bspw. verschiedene Werte)
|
||||
|
||||
### Beispiel Factory Pattern
|
||||
- **Logistik Management Anwendung**
|
||||
- Erste Version kann nur mit LKWs transportieren
|
||||
- Transportation mit Schiff kommt dazu
|
||||
- Code aus LKW Klasse muss teilweise auch in Schiffklasse verwendet werden
|
||||
- Vllt. kommen ja noch mehr Transportmittel dazu?
|
||||
- **Lösung**
|
||||
- 
|
||||
- Objektkreation macht nur die Factory-Methode, spezifisch für das Produkt
|
||||
- In diesem Fall Transport
|
||||
- Logistics ist der Ersteller
|
||||
- Plan für die Lieferung
|
||||
- Definierung der FactoryMethode
|
||||
- ConcreteCreators
|
||||
- 
|
||||
|
||||
### Fazit Factory Method
|
||||
- Implementierung von OO Prinzipien
|
||||
- [OCP](SOLID-Principle.md#o-open-closed-principle-ocp)
|
||||
- Motivierung ist, dass Applikation erweiterbar ist
|
||||
- Client bleibt geschlossen
|
||||
- [LSP](SOLID-Principle.md#l-liskov-s-substitution-principle-lsp)
|
||||
- Kann gestört werden durch unterdrückung der Standardimplementierung durch eine Subklasse
|
||||
- [DIP](SOLID-Principle.md#d-dependency-inversion-principle-dip)
|
||||
- Client definiert/besitzt Interface für Ersteller und Produkte
|
||||
- Bestärkt [Loose Coupling](ImplementingForMaintainability.md#loose-coupling)
|
||||
|
||||
|
||||
## Abstract Factory
|
||||
- Interface für die Erstellung von Familien oder Abhängigkeiten von Objekten
|
||||
|
||||
### Struktur Abstract Factory
|
||||
|
||||
#### AbstractFactory (Interface)
|
||||
- Deklariert Interface fpr Operationen, die Objekte produzieren
|
||||
|
||||
#### ConcreteFactory
|
||||
- Repräsentiert Factory für eine Variante/Familie von Produkten
|
||||
- Implementiert die Operationen, um Objekte zu erstellen
|
||||
|
||||
#### AbstractProduct (Interface)
|
||||
- Deklariert Interface für einen Typ
|
||||
|
||||
#### ConcreteProduct
|
||||
- Definiert konkretes Produkt der Familie
|
||||
|
||||
#### Client
|
||||
- Nutzt nur AbstractFactory und AbstractProduct
|
||||
|
||||
### Beispiel Abstract Factory
|
||||
- 
|
||||
- AbstractProduct
|
||||
- Chair, Sofa, CoffeeTable
|
||||
- Produkt
|
||||
- 3 jeder abstrakten Klasse
|
||||
- Abstract Factory
|
||||
- Interface für FurnitureFactory
|
||||
- ConcreteFactory
|
||||
- Implementierung des AbstractFactory Interface
|
||||
|
||||
### Fazit Abstract Factory
|
||||
- **OO Prinzipien**
|
||||
- [OCP](SOLID-Principle.md#o-open-closed-principle-ocp)
|
||||
- [LSP](SOLID-Principle.md#l-liskov-s-substitution-principle-lsp)
|
||||
- Abhängig von der Implementierung
|
||||
- [DIP](SOLID-Principle.md#d-dependency-inversion-principle-dip)
|
||||
- Client definiert/besitzt Interface für Ersteller und Produkte
|
||||
|
||||
|
||||
## Singleton
|
||||
- Sorgt dafür, dass eine Klasse nur ein Interface hat und dieses global erreichbar ist
|
||||
- Wird genutzt, wenn eine Klasse nur eine einzelne Instanz haben soll
|
||||
- bspw. DatenbankVerbindung
|
||||
|
||||
### Struktur Singleton
|
||||
- Konstruktor hat private Sichtbarkeit
|
||||
- Methode getInstance()
|
||||
- 
|
||||
|
||||
### Beispiel Singleton
|
||||
- 
|
||||
|
||||
### Fazit Singleton
|
||||
- **Probleme**
|
||||
- Pattern löst zwei Probleme gleichzeitig
|
||||
- verletzt [SRP](SOLID-Principle.md#s-single-responsibility-principle-srp)
|
||||
- Kann sychlechtes Design verstecken (bspw. kein Loose Coupling)
|
||||
|
||||
|
||||
## Adapter Pattern
|
||||
- Erlaubt das Nutzen eines Clients mit einem inkompatiblen Interface
|
||||
|
||||
### Structure Adapter Pattern
|
||||
|
||||
#### Target
|
||||
- Definiert domänenspezifisches Interface, das der Client nutzt
|
||||
|
||||
#### Client (Adapter Pattern)
|
||||
- Arbeitet mit Objekten, welche mit dem [Target](#target)-Interace übereinstimmen
|
||||
|
||||
#### Adaptee
|
||||
- Definiert existierendes Interface, welches Adaption benötigt
|
||||
|
||||
#### Adapter
|
||||
- Adaptiert das Interface des Adaptee zum Target-Interface
|
||||
|
||||
#### Collaborations
|
||||
- Client ruft Operationen auf dem Adapter-Interface auf
|
||||
|
||||
### Beispiel Adapter Pattern
|
||||
|
||||
|
||||
|
||||
### Fazit Adapter Pattern
|
||||
- **SRP**
|
||||
- Primäre Business Logik eines Programms ist vom Interface getrennt
|
||||
- **OCP**
|
||||
- Neuer Adapter kann, ohne den existierenden Code zu bearbeiten, erstellt werden
|
||||
|
||||
- Adapter ändert Interface in eins, das der Client erwartet
|
||||
- **Sollte vermieden werden, wenn es möglich ist**
|
||||
|
||||
|
||||
## Facade Pattern
|
||||
- Klasse, die ein simples Interface zu einem komplexen System bereitstellt
|
||||
|
||||
### Struture Facade Pattern
|
||||
|
||||
#### Facade
|
||||
- Weiß, welche Subsystem-Klassen verantwortlich sind
|
||||
- Delegiert Client-Anfragen an Klassen
|
||||
|
||||
#### Subsystem Classes
|
||||
- Implementiert Subsystem Funktionalität
|
||||
- Hat kein Wissen von der Fassade
|
||||
|
||||
#### Collaborations Facade Pattern
|
||||
- Clients kommunizieren mit dem Subsystem durch requests zur Fassade
|
||||
|
||||
### Fazit Facade Pattern
|
||||
- **SRP**
|
||||
- Kann verletzt werden je nach Implementierung
|
||||
|
||||
## Composite Pattern
|
||||
- Baumartige Objektstruktur
|
||||
### Structure Composite Pattern
|
||||
|
||||
|
||||
#### Component (Abstract Class)
|
||||
- Deklariert Interface für Objekte in der Komposition
|
||||
- Implementiert für teilweises default-Verhalten
|
||||
|
||||
#### Leaf
|
||||
- Definiert Verhalten, welches individuell für die Klasse ist
|
||||
|
||||
#### Composite
|
||||
- Definiert Verhalten für Branch-Komponenten
|
||||
|
||||
#### Client (Composite Pattern)
|
||||
- Nutzt Objekte in der Komposition durch das Interface
|
||||
|
||||
### Beispiel Composite Pattern
|
||||
|
||||
|
||||
|
||||
## Strategy Pattern
|
||||
|
||||
|
||||
## State Pattern
|
||||
|
||||
|
||||
29
Writerside/topics/02/OOAD/DesignPrinciples.md
Normal file
29
Writerside/topics/02/OOAD/DesignPrinciples.md
Normal file
@ -0,0 +1,29 @@
|
||||
# Design Principles
|
||||
## [SOLID Design Principles](SOLID-Principle.md)
|
||||
- Fokus auf der Erstellung von Code
|
||||
- Wartbar, Robust, Wiederverwendbar
|
||||
|
||||
### S - Single Responsibility Principle (SRP)
|
||||
- Eine Klasse sollte nur eine einzige Aufgabe / Verantwortung haben
|
||||
### O - Open/Closed Principle (OCP)
|
||||
- Software Komponenten sollten nur fpr Erweiterung, nicht für Modifikation offen sein
|
||||
### L - Liskov's Substitution Principle (LSP)
|
||||
- Basisklassen müssen komplett passend für die erbenden Klassen sein
|
||||
### I - Interface Segregation Principle (ISP)
|
||||
- Clients sollten nicht dazu verpflichtet werden unnötige Methoden zu implementieren
|
||||
### D - Dependency Inversion Principle (DIP)
|
||||
- Abhängig von Abstraktion, nicht Konkretion
|
||||
|
||||
|
||||
## Favor Composition over Inheritance
|
||||
- Vererbung ist ein offensichtlicher Weg um Code von der Basisklasse wiederzuverwenden
|
||||
- Unterklassen können die Codebasis der Basisklassen nicht verkleinern
|
||||
- Methoden des Interfaces müssen alle implementiert werden
|
||||
|
||||
### Composition
|
||||
- Inheritance: _is-a relationship_
|
||||
- Composition
|
||||
- _contains relationship_
|
||||
- Prinzip kann auch auf Aggregation angewendet werden
|
||||
- 
|
||||
|
||||
51
Writerside/topics/02/OOAD/DesigningForMaintainability.md
Normal file
51
Writerside/topics/02/OOAD/DesigningForMaintainability.md
Normal file
@ -0,0 +1,51 @@
|
||||
# Designing for Maintainability
|
||||
|
||||
## [UML (Unified Modeling Language)](UML.md)
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
class AdventurePackage {
|
||||
-title: String
|
||||
-description: String
|
||||
}
|
||||
|
||||
class Trip {
|
||||
-startingDate: Date
|
||||
}
|
||||
|
||||
class Accommodation {
|
||||
-name: String
|
||||
-address: String
|
||||
}
|
||||
|
||||
class Person {
|
||||
-name: String
|
||||
-address: String
|
||||
}
|
||||
|
||||
class Participant {
|
||||
}
|
||||
|
||||
class TourGuide {
|
||||
}
|
||||
|
||||
class Booking {
|
||||
-bookingDate: Date
|
||||
-isPaid: Boolean
|
||||
}
|
||||
|
||||
Person <|-- Participant
|
||||
Person <|-- TourGuide
|
||||
|
||||
AdventurePackage "1" --o "0..*" Trip : contains >
|
||||
Trip "0..*" -- "1" Accommodation : has >
|
||||
Trip "0..*" -- "1" TourGuide : leads >
|
||||
Trip "0..*" -- "0..*" Participant : booked by >
|
||||
|
||||
Participant "1" --o "0..*" Booking : makes >
|
||||
Booking "0..*" -- "1" Trip : for >
|
||||
Booking "0..*" -- "1" Participant : by >
|
||||
|
||||
TourGuide "1" --o "0..*" AdventurePackage : certified for >
|
||||
|
||||
```
|
||||
214
Writerside/topics/02/OOAD/ImplementingForMaintainability.md
Normal file
214
Writerside/topics/02/OOAD/ImplementingForMaintainability.md
Normal file
@ -0,0 +1,214 @@
|
||||
# Implementing for Maintainability
|
||||
|
||||
> **We are NOT DONE when the code works!**
|
||||
|
||||
>_Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live_
|
||||
>
|
||||
> ~_John F. Woods_
|
||||
|
||||
|
||||
## Materials
|
||||
- [Refactoring _by Martin Fowler_](https://learning.oreilly.com/library/view/refactoring-wie/9783958459434/)
|
||||
- [refactoring catalog](https://refactoring.com/catalog/)
|
||||
- [Clean Code _by Uncle Bob_](https://learning.oreilly.com/library/view/clean-code/9783826655487/)
|
||||
|
||||
|
||||
## Introduction
|
||||
- Code wird häufiger gelesen als geschrieben
|
||||
- **Refactoring** ist ein
|
||||
- Prozess, der die Struktur des Codes verbessert, ohne die Funktion zu verändern
|
||||
- disziplinierter Weg den Code zu bereinigen und so die Chance auf Bugs zu minimieren
|
||||
- **Code Smells**
|
||||
- Charakteristik im Code, das etwas falsch sein könnte
|
||||
- Nicht alle Zeichen von Code Smells sind zwingend ein Zeichen von schlechtem Code
|
||||
|
||||
## Refactoring
|
||||
### Rename Variables
|
||||
```c++
|
||||
double a = height * width
|
||||
↓
|
||||
double area = height * width
|
||||
```
|
||||
|
||||
### Replace magic literals
|
||||
```c++
|
||||
2 * 3.14 * radius
|
||||
↓
|
||||
2 * pi * radius
|
||||
```
|
||||
|
||||
### Extract Variable
|
||||
```c++
|
||||
void renderBanner(){
|
||||
if((platform.toUpperCase().indexOf("MAC") > -1) &&
|
||||
(browser.toUpperCase().indexOf("IE") > -1) &&
|
||||
wasInitialized() && resize > 0){
|
||||
//do something
|
||||
}
|
||||
}
|
||||
|
||||
↓
|
||||
|
||||
void renderBanner() {
|
||||
final bool isMacOs = platform.toUpperCase().indexOf("MAC"") > -1;
|
||||
final bool isIE = browser.toUpperCase().indexOf("IE") > -1;
|
||||
final bool wasResized = resize > 0;
|
||||
|
||||
if (isMacOs && isIE && wasResized){
|
||||
//do something
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Extract Function
|
||||
```c++
|
||||
void printOwing(){
|
||||
printBanner();
|
||||
|
||||
//prinz details
|
||||
std::cout << "name: " << name << std::endl;
|
||||
std::cout << "amount: " << getOutstanding() << std::endl;
|
||||
}
|
||||
|
||||
↓
|
||||
|
||||
void printOwing(){
|
||||
printBanner();
|
||||
printDetails(getOutstanding());
|
||||
}
|
||||
|
||||
void printDetails(double outstanding){
|
||||
std::cout << "name: " << name << std::endl;
|
||||
std::cout << "amount: " << outstanding << std::endl;
|
||||
}
|
||||
```
|
||||
|
||||
## Meaningful Names
|
||||
- Namen im Code sollten immer die Intention der Variable/Funktion/Klasse zeigen
|
||||
- Umbenennen, falls nicht
|
||||
- Ein Wort pro Konzept
|
||||
- immer getName() bspw.
|
||||
|
||||
| Solution Domain Names | Problem Domain Names |
|
||||
|-----------------------|----------------------------------------------------------------------|
|
||||
| Developer-Sprache | Code mit Kundenkontakt sollte verständlich für nicht-Entwickler sein |
|
||||
|
||||
## Functions
|
||||
- Sollten klein sein
|
||||
- Nur eine Zeile im body von:
|
||||
- if/else
|
||||
- for-loop
|
||||
- while-loop
|
||||
- Sollten nur eine Aufgabe haben
|
||||
- Geschafft, wenn
|
||||
- es nicht möglich ist eine Funktion daraus zu extrahieren
|
||||
- sie keine Side-Effects haben
|
||||
- sie entweder auf etwas antworten ODER etwas tun
|
||||
- switch-Statements nur, wenn
|
||||
- sie nur einmal vorkommen
|
||||
- sie polymorphe Objekte erzeugen
|
||||
- sie nicht für den Rest des Systems sichtbar sind
|
||||
|
||||
> **Don't Repeat Yourself! (DRY)**
|
||||
|
||||
### Arguments
|
||||
- Weniger Argumente machen den Code lesbarer
|
||||
- **Flag arguments are ugly**
|
||||
- Boolean in Funktion mitgeben zeigt, dass die Funktion mehrere Sachen macht → :(
|
||||
- Ideale Anzahl an Argumenten ist 0
|
||||
- 1 Argument (**monadic**)
|
||||
- Fragen an ein Argument
|
||||
- _bspw. ```boolean file exists(String fileName)```_
|
||||
- Operation an argument ausführen und Ergebnis zurückgeben
|
||||
- Events
|
||||
- Kein Rückgabewert
|
||||
- 2 Argumente (**dyadic**)
|
||||
- schwieriger zu verstehen
|
||||
- Sind manchmal trotzdem sinnvoll
|
||||
- _bspw. wenn man einen Punkt (x, y) mitgibt_
|
||||
- 3 Argumente (**triadic**) (_sollten, wenn möglich, vermieden werden_)
|
||||
- sollten vermieden werden
|
||||
- Mehr Argumente (**polyadic**) (_sollten vermieden werden_)
|
||||
|
||||
### Argument Objects
|
||||
- Wenn eine Funktion mehr als 2-3 Argumente braucht
|
||||
- Objekt erstellen, welches mehrere Argumente zusammenfasst
|
||||
- _bspw. ```double x, double y → Point center```
|
||||
|
||||
### Argument Lists
|
||||
- Falls beliebig viele Argumente mitgegeben werden sollen, diese aber identisch behandelt werden
|
||||
- Zählen als "ein" Argument
|
||||
- _bspw. ```String.format("\%s worked \%.2 hours.", name, hours)```
|
||||
- Ist dyadic
|
||||
|
||||
|
||||
## Comments
|
||||
|
||||
> **Don't comment bad code - rewrite it!**
|
||||
> ~_B.W. Kernighan and P.J. Plaugher_
|
||||
|
||||
### Good comments
|
||||
- gibt es, aber die besten sind die, die du nicht mehr schreiben musst
|
||||
|
||||
#### Legal comments
|
||||
- sind häufig nötig und verständlich
|
||||
- sollten trotzdem vermieden werden, indem auf ein Lizenz-File verwiesen wird
|
||||
- _bspw. Copyright etc._
|
||||
|
||||
#### Informative comments
|
||||
- manchmal sollte man basic Informationen mitgeben, um die Sprache zu verstehen
|
||||
- _bspw. ```//format matched kk:mm:ss``` ```"\\d*:\\d*:\\d*```_
|
||||
|
||||
#### Explanation of Intent
|
||||
- _bspw._ 
|
||||
|
||||
#### Clarification
|
||||
- _bspw._ 
|
||||
|
||||
#### Warning of Consequences
|
||||
- _bspw._ 
|
||||
|
||||
#### TODO Comments
|
||||
- Sollten auch vermieden werden, einfach fertig machen :)
|
||||
|
||||
#### Amplification
|
||||
- Manchmal zeigen Kommentare wie wichtig etwas ist
|
||||
- _bspw._ 
|
||||
|
||||
### Bad Comments
|
||||
- Wenn der Code eh schon verständlich genug ist
|
||||
- Zu viele Informationen
|
||||
- Auskommentierter Code
|
||||
- Nicht verständliche Verbindung zwischen Code und Kommentar
|
||||
|
||||
|
||||
## Formatting / Style Guides
|
||||
> Der beste Stil ist der, der durchgängig ist
|
||||
|
||||
|
||||
## Classes
|
||||
- Sollten klein sein
|
||||
- Wird gemessen in Responsibilities
|
||||
- **Single Responsibility Principle (SRP)**
|
||||
- Klassen sollten nur EINE Aufgabe haben
|
||||
- Führt zu high cohesion
|
||||
|
||||
| low cohesion | high cohesion |
|
||||
|------------------------------------------------------------------------|-------------------------------------------------------------------------|
|
||||
| bewirbt Schwierigkeit zu warten, testen, wiederverwenden, zu verstehen | bewirbt Robustheit, Verständlichkeit, Wiederverwendbarkeit, Reliability |
|
||||
|
||||
|
||||
## Loose Coupling
|
||||
> **Law of Demeter**
|
||||
>
|
||||
> _Talk to Friends, not to Strangers_
|
||||
|
||||
- Ein Freund eines Freundes ist ein Fremder
|
||||
|
||||
|
||||
|
||||
- Minimiere den Grad von Interdependencies
|
||||
|
||||
|
||||
|
||||
|
||||
75
Writerside/topics/02/OOAD/IntroductionOOAD.md
Normal file
75
Writerside/topics/02/OOAD/IntroductionOOAD.md
Normal file
@ -0,0 +1,75 @@
|
||||
# Introduction
|
||||
|
||||
## What is Software Engineering
|
||||
> **Definition according to Ian Sommerville**<br/>
|
||||
> Software engineering is an _engineering discipline_ that is concerned with all aspects of
|
||||
> _software production_ from the early stages of system specification through to maintaining
|
||||
> the system after it has gone into use.
|
||||
|
||||
| ...Ingenieurdisziplin... | ...alle Aspekte der Softwareproduktion... |
|
||||
|------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------|
|
||||
| Ingenieure lassen Dinge funktionieren! | nicht nur die Softwareentwicklung |
|
||||
| Sie wenden Theorien, Methoden und Werkzeuge dort an, wo diese angemessen sind | beinhaltet auch Aktivitäten wie _Projektmanagement_, Entwicklung von Werkzeugen, Methoden und Theorien zur Unterstützung |
|
||||
| Lösungen **müssen** innerhalb organisatorischer und finanzieller Einschränkungen funktionieren | |
|
||||
|
||||
|
||||
## Iron Triangle: Organizational and Financial Constraints
|
||||
|
||||
- visualisiert Einschränkungen im Projektmanagement
|
||||
- verkündet:
|
||||
1. Qualität der Ergebnisse eines Projekts ist durch folgende Faktoren eingeschränkt:
|
||||
- Kosten (_verfügbar: Budget, Ingenieure, ..._)
|
||||
- Zeit (_verfügbar: Zeit, Fristen_)
|
||||
- Umfang (_Funktionen, bereitgestellte Funktionalität_)
|
||||
2. PM kann zwischen Einschränkungen handeln
|
||||
3. Änderungen in einer Einschränkung erfordern Änderungen in anderen zur Kompensation, oder die Qualität wird leiden
|
||||
- Die Realität ist komplexer
|
||||
- Geld in ein vollständig ausgelastetes Projekt zu stecken, kann es verlangsamen
|
||||
|
||||
## Software Development Lifecycle (SDLC)
|
||||
```mermaid
|
||||
stateDiagram
|
||||
1: Requirement Analysis
|
||||
2: Design
|
||||
3: Implementation
|
||||
4: Testing
|
||||
5: Maintaining/Operations
|
||||
1-->2
|
||||
2-->3
|
||||
3-->4
|
||||
4-->5
|
||||
5-->1
|
||||
```
|
||||
### Requirement Analysis
|
||||
- Understand what your client wants and/or needs
|
||||
### Design
|
||||
- Design a solution that meets [functional/non-functional](IntroductionOOAD.md#requirements-in-software-engineering) requirements
|
||||
### Implementation
|
||||
- Actually build the system meeting required quality goals
|
||||
### Testing
|
||||
- Ensure that the whole system meets all requirements
|
||||
### Maintaining/Operations
|
||||
- The system serves its purpose (earns money)
|
||||
|
||||
## Software Quality
|
||||
### Requirements in Software Engineering
|
||||
| **Functional Requirements (FR)** | **Non-Functional Requirements (NFR)** |
|
||||
|------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Systemfunktionen, Anwendungsfälle, ... | Eigenschaften des Systems als Ganzes, nicht im Zusammenhang mit der Funktionalität (_bspw. Sicherheit, Performance, Wartbarkeit_) |
|
||||
| Können unterschiedlich detailliert erfasst sein (je nach Komplexität des Projekts) | Beeinflussen die gesamte Architektur eines Systems, nicht nur einzelne Komponenten |
|
||||
| FRs sind meist höchste Prio des Clients, aber auch am einfachsten zu verhandeln | Wenn ein NFR scheitert, kann das ganze System nicht funktionieren |
|
||||
|
||||
|
||||
### Eight Quality Characteristics
|
||||
|
||||
|
||||
### Maintainability
|
||||
- Modularität
|
||||
- Wiederverwendbarkeit
|
||||
- Analysierbarkeit
|
||||
- Modifizierbarkeit
|
||||
- Testbarkeit
|
||||
|
||||
>_Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live_
|
||||
>
|
||||
> ~_John F. Woods_
|
||||
107
Writerside/topics/02/OOAD/Praktikum3_Diagramme.md
Normal file
107
Writerside/topics/02/OOAD/Praktikum3_Diagramme.md
Normal file
@ -0,0 +1,107 @@
|
||||
```mermaid
|
||||
classDiagram
|
||||
class Person
|
||||
<<abstract>> Person
|
||||
Person : - name
|
||||
Person : - adress
|
||||
class Tourguide
|
||||
Tourguide : - certifiedAdventurePackages <AdventurePackage*> vector
|
||||
class Participant
|
||||
class AdventurePackage
|
||||
AdventurePackage : - title
|
||||
AdventurePackage : - description
|
||||
class Accommodation
|
||||
Accommodation : - name
|
||||
Accommodation : - adress
|
||||
class Trip
|
||||
Trip : - startingDate
|
||||
|
||||
class Booking
|
||||
Booking : - payed
|
||||
Booking : - dateOfBooking
|
||||
|
||||
Tourguide --|> Person
|
||||
Participant --|> Person
|
||||
Trip "1..*" o-- "1..*" AdventurePackage
|
||||
Trip "*" o-- "1" Accommodation
|
||||
Participant "1..*" -- "1..*" Trip: Booking
|
||||
Participant "1..*" .. Booking
|
||||
Booking "1..*" .. "1..*" Trip
|
||||
Tourguide "1" --o "*" Trip
|
||||
Tourguide "1..*" -- "1..*" AdventurePackage
|
||||
```
|
||||
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
actor Tom as Tom : Human
|
||||
participant LibGui as libGUI
|
||||
participant Lib as Lib
|
||||
participant CTom as Tom : Customer
|
||||
activate LibGui
|
||||
|
||||
Tom -) LibGui: name = "HP1"
|
||||
|
||||
LibGui ->>+ Lib: getEbook("HP1")
|
||||
|
||||
create participant EBook as HP1 : EBook
|
||||
Lib -->>+ EBook: <<create>> EBook("HP1", 3.99)
|
||||
note right of EBook: Im Konstruktor von EBook fehlt<br/>die Zuweisung des Preise.<br/>Hier ergänzt
|
||||
|
||||
EBook --)- Lib: return
|
||||
Lib --)- LibGui: return
|
||||
|
||||
LibGui --)+ Tom: return
|
||||
Tom -)- LibGui: clickBorrowButton
|
||||
|
||||
LibGui ->>+ Lib: getEbook("HP1")
|
||||
Lib ->>+ CTom: borrow("HP1")
|
||||
CTom ->>+ EBook: getPrice()
|
||||
EBook --)- CTom: return 3.99
|
||||
|
||||
CTom ->> CTom: charge(3.99)
|
||||
|
||||
CTom --)- Lib: return
|
||||
|
||||
Lib --)- LibGui: return
|
||||
|
||||
LibGui ->>+ EBook: generateLink()
|
||||
EBook --)- LibGui: return link
|
||||
|
||||
activate LibGui
|
||||
LibGui ->> LibGui: showLink()
|
||||
LibGui --)- LibGui: return
|
||||
|
||||
LibGui --) Tom: return
|
||||
|
||||
destroy EBook
|
||||
LibGui -x EBook: <<destroy>>
|
||||
|
||||
destroy CTom
|
||||
LibGui -x CTom: <<destroy>>
|
||||
|
||||
destroy Lib
|
||||
LibGui -x- Lib: <<destroy>>
|
||||
|
||||
destroy LibGui
|
||||
Tom --x LibGui: <<destroy>>
|
||||
```
|
||||
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
class Kreis{
|
||||
<<abstract>>
|
||||
- radius : ft
|
||||
+ setRadius()
|
||||
}
|
||||
class Ellipse{
|
||||
- breite : ft
|
||||
- hoehe : ft
|
||||
+ setBreite()
|
||||
+ setHoehe()
|
||||
}
|
||||
|
||||
Ellipse --|> Kreis
|
||||
```
|
||||
|
||||
124
Writerside/topics/02/OOAD/Praktikum4_Diagramme.md
Normal file
124
Writerside/topics/02/OOAD/Praktikum4_Diagramme.md
Normal file
@ -0,0 +1,124 @@
|
||||
```plantuml
|
||||
@startuml
|
||||
class Subject <<abstract>>{
|
||||
+ ~Subject()
|
||||
+ attach(obersever: Observer*): void
|
||||
+ detach(observer: Observer*): void
|
||||
+ notify(): void
|
||||
}
|
||||
|
||||
class Observer <<interface>>{
|
||||
+ {abstract} update(): void
|
||||
+ ~Observer()
|
||||
}
|
||||
|
||||
class SystemBattery{
|
||||
+ setBatteryLevel(data: int): void
|
||||
+ getData(): int
|
||||
- BatteryLevel: int
|
||||
}
|
||||
|
||||
class BatteryApp{
|
||||
+ BatteryApp(subject: SystemBattery&, name: string)
|
||||
+ update(): void
|
||||
- name: string
|
||||
}
|
||||
|
||||
class BatteryLogger{
|
||||
+ BatteryLogger(subject: SystemBattery&, name: string)
|
||||
+ update(): void
|
||||
- name: string
|
||||
}
|
||||
|
||||
Subject <|-- SystemBattery
|
||||
Observer <|-- BatteryApp
|
||||
Observer <|-- BatteryLogger
|
||||
|
||||
SystemBattery "1" *- "*" BatteryApp: - subject: SystemBattery&
|
||||
SystemBattery "1" *- "*" BatteryLogger: - subject: SystemBattery&
|
||||
Subject "*" -o "*" Observer: - observers: list<Observer*>
|
||||
|
||||
|
||||
@enduml
|
||||
```
|
||||
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
actor human
|
||||
activate human
|
||||
create participant Main
|
||||
human -)+ Main: <<create>>
|
||||
|
||||
Note over Main: create Observers and Subject
|
||||
create participant SystemBattery as systemBattery: Subject
|
||||
Main ->>+ SystemBattery: <<create>>
|
||||
SystemBattery --)- Main: return
|
||||
|
||||
create participant Observer as batteryApp: Observer
|
||||
Main ->>+ Observer: <<create>>(SystemBattery* = *systemBattery, name = "BatteryApp")
|
||||
Observer->>+ SystemBattery: attach(this)
|
||||
SystemBattery ->> SystemBattery: observers.push_back(batteryApp)
|
||||
SystemBattery --)- Observer: return
|
||||
Observer --)- Main: return
|
||||
|
||||
create participant Logger as batteryLogger: Observer
|
||||
Main ->>+ Logger: <<create>>(SystemBattery* = *systemBattery, name = "BatteryLogger")
|
||||
Logger->>+ SystemBattery: attach(this)
|
||||
SystemBattery ->> SystemBattery: observers.push_back(batteryLogger)
|
||||
SystemBattery --)- Logger: return
|
||||
Logger --)- Main: return
|
||||
|
||||
Note over Main: Set BatteryLevel to 87
|
||||
Main ->>+ SystemBattery: setBatteryLevel(data = 87)
|
||||
activate SystemBattery
|
||||
SystemBattery -->> SystemBattery: BatteryLevel = data
|
||||
SystemBattery --) human: "New value 87
|
||||
|
||||
%% Loop for each observer
|
||||
note over SystemBattery: update each Observer
|
||||
SystemBattery ->>+ SystemBattery: notify()
|
||||
SystemBattery ->>+ Observer: update()
|
||||
Observer ->>+ SystemBattery: getData()
|
||||
SystemBattery --)- Observer: return BatteryLevel
|
||||
Observer -->> Observer: newValue = BatteryLevel
|
||||
Observer --) human: "This is batteryApp! Received value 87"
|
||||
Observer --)- SystemBattery: return
|
||||
|
||||
SystemBattery ->>+ Logger: update()
|
||||
Logger ->>+ SystemBattery: getData()
|
||||
SystemBattery --)- Logger: return BatteryLevel
|
||||
Logger -->> Logger: newValue = BatteryLevel
|
||||
Logger --) human: "TThis is batteryLogger! Received value 87! Will proceed to log value into file..."
|
||||
Logger -->> Logger: log data into file
|
||||
Logger --)- SystemBattery: return
|
||||
%% end loop
|
||||
deactivate SystemBattery
|
||||
SystemBattery --)- Main: return
|
||||
|
||||
Note over Main: delete created Objects
|
||||
Main --x Observer: <<delete>>
|
||||
activate Observer
|
||||
Observer ->>+ SystemBattery: detach(this)
|
||||
SystemBattery ->> SystemBattery: overservers.remove(batteryApp)
|
||||
deactivate Observer
|
||||
destroy Observer
|
||||
SystemBattery --)- Observer: return
|
||||
|
||||
Main --x Logger: <<delete>>
|
||||
activate Logger
|
||||
Logger ->>+ SystemBattery: detach(this)
|
||||
SystemBattery ->> SystemBattery: overservers.remove(batteryLogger)
|
||||
deactivate Logger
|
||||
destroy Logger
|
||||
SystemBattery --)- Logger: return
|
||||
|
||||
destroy SystemBattery
|
||||
Main --x SystemBattery: <<delete>>
|
||||
|
||||
Main --)- human: return
|
||||
|
||||
destroy Main
|
||||
human --x Main: <<destroy>>
|
||||
deactivate human
|
||||
```
|
||||
113
Writerside/topics/02/OOAD/RequirementsAnalysis.md
Normal file
113
Writerside/topics/02/OOAD/RequirementsAnalysis.md
Normal file
@ -0,0 +1,113 @@
|
||||
# Requirements Analysis
|
||||
## Domain Diagram
|
||||
- Konzeptuelles Modell um ein gemeinsames Vokabular im Projekt-Team zu etablieren
|
||||
### Problem Domain
|
||||
- Devs haben ein gemeinsames Verständnis von Lösungen
|
||||
|
||||
### Solution Domain
|
||||
- Es muss ein gemeinsames Verständnis von dem Arbeitsumfeld des Klienten geschaffen werden
|
||||
|
||||
### Beispiel Domain Diagram
|
||||
|
||||
- Zeigt die wichtigsten Problem-Domains und ihre Verbindungen
|
||||
|
||||
|
||||
## UML Use Case Diagram
|
||||
- System Anforderungen erfassen
|
||||
- NUR [Functional Requirements](IntroductionOOAD.md#requirements-in-software-engineering)
|
||||
|
||||
### Notation
|
||||
#### Actor
|
||||
- 
|
||||
- Identifizierung:
|
||||
- 
|
||||
|
||||
#### Use Case
|
||||
|
||||
|
||||
#### Communication Lines
|
||||
|
||||
|
||||
#### System Boundaries
|
||||
|
||||
|
||||
|
||||
## User Stories
|
||||
### Definition
|
||||
- Beschreiben funktionalen Wert für einen Nutzer des Systems / der Software
|
||||
- Aspekte
|
||||
1. **Card**
|
||||
- Beschreibung der Story
|
||||
- Genutzt für Planung, Erinnerung
|
||||
- Traditionell Handschriftlich
|
||||
- Repräsentiert Kunden-Anforderungen
|
||||
- nicht Dokumentation
|
||||
2. **Conversation**
|
||||
- Gibt Details über Story
|
||||
- Wichtigster Teil der User Story
|
||||
- Werden mit dem Kunden vor der Entwicklung diskutiert
|
||||
3. **Confirmation**
|
||||
- Akzeptierungskriterien (Tests)
|
||||
- Dokumentation der Konversation
|
||||
- Können entscheidend sein, wann eine Story abgeschlossen ist
|
||||
|
||||
##### Beispiel UserStory: Job Posting und Search-Website
|
||||
- Ein Nutzer kann nach Jobs suchen
|
||||
- Eine Firma kann eine offene Stelle posten
|
||||
- Ein Nutzer kann einstellen, wer seinen Lebenslauf sehen kann
|
||||
|
||||
|
||||
|
||||
### Good User Stories: INVEST Criteria
|
||||
|
||||
|
||||
#### I - Independent
|
||||
- Unabhängig von allen anderen Stories
|
||||
- Stories sollten in allen möglichen Reihenfolgen bearbeitet werden können
|
||||
- Falls eine enge Kupplung besteht
|
||||
- MERGE
|
||||
- **Beispiel:**
|
||||
- 
|
||||
|
||||
#### N - Negotiable
|
||||
- Stories sind keine festen Verträge
|
||||
- Kurze Beschreibung von Funktionalität
|
||||
- Details müssen in Konversation zwischen Kunde und Team verhandelt werden
|
||||
- Falls wichtige Details vorher bekannt sind
|
||||
- als Annotation inkludieren
|
||||
- **Beispiel:**
|
||||
- 
|
||||
|
||||
#### V - Valuable
|
||||
- **Beispiel:**
|
||||
- 
|
||||
|
||||
#### E - Estimable
|
||||
- Devs müssen workload abschätzen können
|
||||
- **Gegenbeispiel:**
|
||||
- 
|
||||
|
||||
#### S - Small
|
||||
|
||||
|
||||
#### T - Testable
|
||||
|
||||
## Gathering Stories
|
||||
- **Nutzer-Interviews**
|
||||
- Standard
|
||||
- Wichtig:
|
||||
- Echte Nutzer befragen
|
||||
- Fragen sollten offen und kontextfrei sein
|
||||
- **Umfragen**
|
||||
- Für weitere Details in bekannten Stories
|
||||
- Beispielfragen:
|
||||
- Wie oft nutzt du [Feature]
|
||||
- Warum nutzt du [Feature] nicht mehr
|
||||
- **Beobachtungen**
|
||||
- Nutzer beobachten, während Nutzung befragen
|
||||
- Seltene Möglichkeit zur Durchführung
|
||||
- Wenn dann da: NUTZEN!
|
||||
- **Story-Writing-Workshops**
|
||||
- Meeting mit Devs, Nutzer, Produkt-Kunde, andere Beteiligte
|
||||
- Schnellste Möglichkeit für neue Stories
|
||||
- Führen des Workshops benötigt Erfahrung
|
||||
90
Writerside/topics/02/OOAD/SOLID-Principle.md
Normal file
90
Writerside/topics/02/OOAD/SOLID-Principle.md
Normal file
@ -0,0 +1,90 @@
|
||||
# SOLID
|
||||
|
||||
## S - Single Responsibility Principle (SRP)
|
||||
- Änderungen entstehen, wo Verantwortung ist
|
||||
- Verantwortung ist ein Grund zur Änderung
|
||||
- Falls eine Klasse mehr als eine Verantwortung hat
|
||||
- Verantwortungen werden gruppiert :(
|
||||
- Führt zu [fragilem Design](AgileDesign.md#fragility-zerbrechlichkeit)
|
||||
|
||||
### Beispiel SRP Verletzung
|
||||
- 
|
||||
- Erzeugte Probleme
|
||||
- GUI muss in computionalGeometryApplication inkludiert werden
|
||||
- Änderungen in Graphical führen zu Änderungen in computional
|
||||
- Besser:
|
||||
- 
|
||||
|
||||
### Was ist eine Responsibility
|
||||
- Ein Grund zur Änderung
|
||||
- Wenn jemandem mehr als eine Idee einfällt, warum man die Klasse ändern könnte
|
||||
- Mehrere Responsibilitys
|
||||
|
||||
|
||||
## O - Open/Closed Principle (OCP)
|
||||
- Änderungen an einzelnen Dateien sollen sich nicht auf andere Klassen auswirken
|
||||
- Lieber neuen Code statt Code zu ändern, der funktioniert
|
||||
- Wird durch Abstraktion erreicht
|
||||
- Abstraktion ist nach außen fest
|
||||
- Geerbte Klassen können Methoden neu zu ihren Bedürfnissen anpassen
|
||||
|
||||
### Beispiel OCP Verletzung
|
||||
- 
|
||||
- Client nutzt Server Klasse
|
||||
- Falls Server sich clientseitig ändert gehts teilweise nicht mehr
|
||||
- Besser:
|
||||
- 
|
||||
|
||||
### Wann OCP anwenden?
|
||||
- Gegen welche Änderungen möchte man sich schützen?
|
||||
- Nicht gegen die falschen Änderungen
|
||||
- häufig falsch, aber passiert
|
||||
- Häufig unnötig → [Needless Complexity](AgileDesign.md#needless-complexity)
|
||||
|
||||
|
||||
## L - Liskov's Substitution Principle (LSP)
|
||||
- Subtypen müssen passend zu ihren Basisklassen sein
|
||||
- Macht OCP besser
|
||||
|
||||
### Beispiel LSP Verletzung
|
||||
- 
|
||||
- Pinguin kann nicht fliegen → :(
|
||||
- Besser:
|
||||
- 
|
||||
|
||||
|
||||
## I - Interface Segregation Principle (ISP)
|
||||
- Niemanden dazu zwingen Interfaces zu nutzen
|
||||
- 
|
||||
|
||||
### Beispiel ISP Verletzung
|
||||
- 
|
||||
- Besser
|
||||
- 
|
||||
|
||||
### Conclusion ISP
|
||||
- Fette Klassen erzeugen schädigende Kupplung zwischen ihren Klienten
|
||||
|
||||
|
||||
## D - Dependency Inversion Principle (DIP)
|
||||
- Abstraktionen sollten nicht von Details abhängig sein
|
||||
- DIP behandelt Besitztum und Abhängigkeiten
|
||||
- Detaillierte Implementierungen definieren die Abstraktion, von der sie abhängig sind
|
||||
|
||||
### Naive Layering System
|
||||
- High Level Policy Layer
|
||||
- Lower Level Mechanism Layer
|
||||
- Detailed Level Utility Layer
|
||||
|
||||
### Inversion of Ownership
|
||||
- 
|
||||
|
||||
### When to use the DIP?
|
||||
- Nichts sollte von einer konkreten Klasse abhängig sein
|
||||
- Keine Variable sollte einen Pointer auf eine andere Klasse enthalten
|
||||
- Keine Methode sollte eine bereits implementierte Methode seiner Basisklasse überschreiben
|
||||
|
||||
### Conclusion DIP
|
||||
- Sowohl Policies als auch Detail basieren auf Abstraktion
|
||||
- Fundamentaler low-level Mechanismus hinter OOAD
|
||||
|
||||
92
Writerside/topics/02/OOAD/SoftwareProcesses.md
Normal file
92
Writerside/topics/02/OOAD/SoftwareProcesses.md
Normal file
@ -0,0 +1,92 @@
|
||||
# Software Processes
|
||||
In den 1950ern wurde Software an Seite der Hardware entwickelt
|
||||
- Ziel dieser Prozesse war das komplette Produkt in einem einzigen Projekt zu entwerfen
|
||||
|
||||
## Classic Organizational Structure
|
||||
- **Business or Client**
|
||||
- braucht neue Software/System
|
||||
- Definiert Kriterien, welche für die Vollständigkeit des Systems essenziell sind
|
||||
- Definiert _[requirements specification](IntroductionOOAD.md#requirements-in-software-engineering)_, welche das benötigte System beschreibt
|
||||
- **Entwicklungsteam oder Software-Firma**
|
||||
- Bekommt _requirements specification_
|
||||
- Designt und entwickelt das System anhand der gegebenen Spezifikationen
|
||||
- Erstellt ein Handbuch
|
||||
- **Operations Team**
|
||||
- Bekommt Handbuch
|
||||
- Nimmt Rechenschaft für das Laufen der Software auf sich
|
||||
- Gibt auftretende Fehler an das Entwicklungsteam weiter
|
||||
|
||||
|
||||
## Handling of Change: Implications
|
||||
Ursprüngliches Projekt ist fertig - Kunde ist aber nicht glücklich
|
||||
- Ein neues Projekt startet den SDLC neu
|
||||
- 
|
||||
|
||||
## Waterfall Model
|
||||
- Sequenzielle Ausführung der Phasen des [SDLC](IntroductionOOAD.md#software-development-lifecycle-sdlc)
|
||||
- Jede Phase wird mit einer Dokumentation des Schritts beendet
|
||||
- Iterationen sind nur zwischen zwei aufeinanderfolgenden Phasen möglich
|
||||
- 
|
||||
- [](SoftwareProcesses.md#classic-organizational-structure)
|
||||
|
||||
## Neue Modelle
|
||||
### V-Modell
|
||||
|
||||
### Spiral-Modell
|
||||
|
||||
|
||||
## Agile
|
||||
### The Agile Manifesto
|
||||
#### 4 Werte
|
||||
- **Individuen und Interaktionen** über _Prozesse und Werkzeuge_
|
||||
- **Funktionierende Software** über _verständliche Dokumentation_
|
||||
- **Arbeit mit Kunden** über _Vertragsverhandlungen_
|
||||
- **Anpassung an Veränderung** über _folgen des Plans_
|
||||
|
||||
#### 12 Prinzipien
|
||||
- Funktionierende Software ist die primäre Ressource um den Fortschritt zu messen
|
||||
- Die höchste Priorität ist den Kunden durch frühe und durchgehende Lieferung von wertvoller Software glücklich zu machen
|
||||
- Liefere funktionierende Software regelmäßig, ~mehrere Wochen bis mehrere Monate → kürzer = besser
|
||||
- Durchgehende Aufmerksamkeit auf technische Exzellenz und gutes Design verbessert die Agilität
|
||||
|
||||
### Strongly Iterative Development
|
||||
Verstärkt durchgehende Kreation von Nutzen für Kunden
|
||||
- Scope: wichtigsten Features der Iteration
|
||||
- 
|
||||
|
||||
Durchgehende Anpassung der Anforderungen an aktuelle Nachfrage
|
||||
- 
|
||||
|
||||
### Small and Cross-functional Teams
|
||||
- Selbst organisiert, divers, T-shaped skills
|
||||
- klein
|
||||
- 
|
||||
- Beispiel Scrum Team:
|
||||
- **3-9 Developers**
|
||||
- verantwortlich für alle Aspekte der Entwicklung
|
||||
- **1 Product Owner**
|
||||
- spielt Kunde für die Devs, kreiert und priorisiert Features
|
||||
- **1 Scrum Master**
|
||||
- Coach, Prozess-Authorität
|
||||
|
||||
Business/Client wird Teil des Teams
|
||||
- Product Owner
|
||||
- 
|
||||
|
||||
|
||||
## DevOps
|
||||
Erweiterung der agilen [Software-Entwicklung](SoftwareProcesses.md#agile)
|
||||
- nicht nur Dev (_Entwicklung_), sondern auch Ops(_Operations_)
|
||||
|
||||
- Gefördert durch dynamische Cloud-Infrastuktur
|
||||
- Führt zu höherer Qualität
|
||||
- Devs machen stabileren Code
|
||||
- fördert Automatisierung in allen Aspekten
|
||||
|
||||
DevOps fördert schnellere Iterationen
|
||||
- Features können individuell ausgeliefert werden
|
||||
- mehrere Releases am Tag sind normal
|
||||
- schnellere Feedback-Cycles
|
||||
- Bessere Adaption zu neuen Anforderungen
|
||||
- Nutzer-Verhalten kann aufgezeichnet und für spätere Arbeit genutzt werden
|
||||
|
||||
28
Writerside/topics/02/OOAD/UML.md
Normal file
28
Writerside/topics/02/OOAD/UML.md
Normal file
@ -0,0 +1,28 @@
|
||||
# UML (Unified Modeling Language)
|
||||
## Categories
|
||||
### Structure Diagrams
|
||||
- dynamisches Verhalten der Elemente (bspw. Veränderung über Zeit) wird nicht beachtet
|
||||
|
||||
- **[Class Diagram](UMLKlassenDiagramme.md)**
|
||||
- Package Diagram
|
||||
- **[Object Diagram](UMLKlassenDiagramme.md#objekt-diagramme)**
|
||||
- Component Diagram
|
||||
- Profile Diagram
|
||||
- Composition Structure Diagram
|
||||
- Deployment Diagram
|
||||
|
||||
### Behavior Diagram
|
||||
- Kann Verhalten detailliert definieren
|
||||
- Bestimmt, wie sich der Zustand eines Elements über Zeit verändert
|
||||
|
||||
- **[State Machine Diagram](UMLStateDiagramme.md)**
|
||||
- **Use Case Diagram**
|
||||
- Activity Diagram
|
||||
- Interaction Diagram
|
||||
- **[Sequence Diagram](UMLSequenzDiagramme.md)**
|
||||
- Interaction Overview Diagram
|
||||
- Communication Diagram
|
||||
- Timing Diagram
|
||||
|
||||
|
||||
|
||||
161
Writerside/topics/02/OOAD/UMLKlassenDiagramme.md
Normal file
161
Writerside/topics/02/OOAD/UMLKlassenDiagramme.md
Normal file
@ -0,0 +1,161 @@
|
||||
# Klassen Diagramme
|
||||
|
||||
https://www.hanser-elibrary.com/doi/epdf/10.3139/9783446431973
|
||||
|
||||
- Klassen werden als Boxen dargestellt mit
|
||||
- Name
|
||||
- Attribute
|
||||
- Methoden
|
||||
|
||||
### Aufbau Klassen-Diagramm
|
||||
#### 1. Bereich: Name der Klasse
|
||||
- beginnt mit Großbuchstaben
|
||||
- ist ein Nomen
|
||||
- sollte die Klasse beschreiben
|
||||
#### 2. Bereich: Attribute der Klasse
|
||||
Es gibt zwei Arten die Attribute darzustellen
|
||||
- Inline, dabei muss angegeben werden:
|
||||
- [Sichtbarkeit](UMLKlassenDiagramme.md#sichtbarkeit-von-attributen-methoden)
|
||||
- Name
|
||||
- Typ (primitiv / komplex)
|
||||
- Durch [Assoziation](UMLKlassenDiagramme.md#association)
|
||||
- bspw.: entries 
|
||||
#### 3. Bereich: Methoden der Klasse
|
||||
- Haben 4 Elemente:
|
||||
- [Sichtbarkeit](UMLKlassenDiagramme.md#sichtbarkeit-von-attributen-methoden)
|
||||
- Name
|
||||
- ggf Parameter
|
||||
- Rückgabewert
|
||||
- Bspw.: ```+ addEntry(int number, string description): void```
|
||||
|
||||
### Sichtbarkeit von Attributen / Methoden
|
||||
- **Public (+)**
|
||||
- Jedes Objekt anderer Klassen kann zugreifen
|
||||
- **Protected (#)**
|
||||
- Jedes Objekt der Klasse und der Unterklassen kann darauf zugreifen
|
||||
- **Package (~)**
|
||||
- Jedes Objekt, deren Klasse im selben Package ist, kann darauf zugreifen
|
||||
- **Private (-)**
|
||||
- Nur das Objekt selbst kann darauf zugreifen
|
||||
|
||||
### Beispiel Klassen Diagramme:
|
||||
- 3 Klassen (Student, Course, LectureHall)
|
||||
- Student kann keine bis n Lectures beitreten
|
||||
- Courses können in keine bis einer LectureHall stattfinden
|
||||
- Student hat einen first name, last name, date of birth...
|
||||
- etc.
|
||||
|
||||
|
||||
|
||||
|
||||
### Erstellung eines Klassen-Diagramms
|
||||
1. Identifizierung der Klassen
|
||||
- 
|
||||
2. Identifizierung der Attribute
|
||||
- 
|
||||
3. Identifizierung von Generalisierungen
|
||||
- 
|
||||
4. Identifizierung von Assoziationen und Aggregationen
|
||||
- 
|
||||
|
||||
_Entstandenes UML-Diagramm ist nicht einzig korrektes!_
|
||||
|
||||
## Objekt Diagramme
|
||||
### Beispiel Objekt Diagramme:
|
||||
- 4 Instanzen / Objekte vom Typ Student (Helen, Mike, Paul)
|
||||
- Helen ist im Kurs oom und iprog
|
||||
- Der Kurs db ist in der LectureHall lh2
|
||||
- 
|
||||
|
||||
## Relationship Overview
|
||||
Klassen arbeiten zusammen über verschiedene Arten von Relationships
|
||||
|
||||
- Relationships werden als Linie zwischen den Boxen dargestellt mit
|
||||
- Name
|
||||
- Leserichtung
|
||||
- Multiplizität
|
||||
- Sind als Intervall dargestellt _[Min..Max]_
|
||||
- Falls es kein Limit gibt: *
|
||||
- Falls Min = Max: nur eins hinschreiben
|
||||
- Bsp.:
|
||||
- ```[0..1]```: Attribut hat 0 - 1 Wert
|
||||
- ```[5]```: Attribut hat genau 5 Werte
|
||||
- ```[*]```: Attribut hat 0 bis unendlich Werte
|
||||
- ```[3..*]```: Attribut hat 3 bis unendlich Werte
|
||||
|
||||
### Association
|
||||
Wenn ein Objekt einer Klasse mit Objekten einer anderen Klasse arbeitet
|
||||
|
||||
|
||||
- schwächstes Relationship
|
||||
- Kommunikationspartner können auf Attribute und Methoden des Anderen zugreifen
|
||||
- Bsp.:
|
||||
- 
|
||||
|
||||
#### Navigatability
|
||||
- **x**: Darauf ist nicht zugreifbar
|
||||
- **>**: Darauf kann zugegriffen werden
|
||||
- nix: undefined
|
||||
|
||||
|
||||
### Aggregation
|
||||
Wenn eine Klasse eine Referenz zu Objekten einer anderen Klasse besitzt und teilt
|
||||
|
||||
|
||||
|
||||
- Objekte existieren auch unabhängig
|
||||
- Es können auch [mehrere Objekte](UMLKlassenDiagramme.md#relationship-overview) in einer Aggregation verbunden werden
|
||||
|
||||
### Composition
|
||||
Wenn eine Klasse Objekte einer anderen Klasse enthält
|
||||
|
||||
|
||||
|
||||
- Nur maximal eine Instanz
|
||||
- Objekt kann nicht allein existieren
|
||||
|
||||
### Generalization (Inheritance)
|
||||
Wenn eine Klasse ein Typ einer anderen Klasse ist
|
||||
|
||||
|
||||
|
||||
|
||||
## Erstellung von Klassen
|
||||
### Appropriate Level of detail
|
||||
Detail der Zeichnung sollte abhängig vom [SDLC](IntroductionOOAD.md#software-development-lifecycle-sdlc) sein.
|
||||
1. keine Details (erste Analyse für die ersten Diskussionen des Domänen-Konzepts)
|
||||
- 
|
||||
2. mehr Details (während späterer Analysen)
|
||||
- 
|
||||
3. sehr detaillierte Beschreibung (detaillierte Analyse oder während Implementierung)
|
||||
- 
|
||||
|
||||
## N-Ary Association
|
||||
- Relationship zwischen mehr als zwei Klassen
|
||||
- Wird durch hohle Raute in der Mitte der Klassen dargestellt
|
||||
- bspw.: 
|
||||
|
||||
### Implementierung in Code von N-Ary Association
|
||||
- nicht existent in Standard-Programmiersprachen
|
||||
|
||||
#### Using Two Binary Associations
|
||||
|
||||
|
||||
#### Using additional Class
|
||||
|
||||
|
||||
## Association Class
|
||||
### Introduction Association Class
|
||||
Erlaubt [N-Ary Associations](UMLKlassenDiagramme.md#n-ary-association)
|
||||
|
||||
### Possible Implementations of Association Classes
|
||||
 
|
||||
|
||||
|
||||
## Abstract Class
|
||||
|
||||
|
||||
- nur im Kontext von Generalisierungsbeziehungen sinnvoll
|
||||
|
||||
## Interface
|
||||
|
||||
78
Writerside/topics/02/OOAD/UMLSequenzDiagramme.md
Normal file
78
Writerside/topics/02/OOAD/UMLSequenzDiagramme.md
Normal file
@ -0,0 +1,78 @@
|
||||
# Sequenz Diagramme
|
||||
gehören in die Kategorie der Verhaltensdiagramme in UML
|
||||
|
||||
Beispiel:
|
||||
|
||||
|
||||
|
||||
## Time
|
||||
- Zeit läuft von oben nach unten
|
||||
- Abstand zwischen den einzelnen Elementen hat nichts mit der Dauer derer zu tun
|
||||
|
||||
## Participants
|
||||
- Repräsentieren den Teil des Systems, welcher miteinander interagiert
|
||||
- Jeder Teilnehmer hat eine lifeline
|
||||
|
||||
### Participant Names
|
||||
- Format: _role [selector] : class_name_
|
||||
- bspw.:
|
||||
- admin - wird admin genannt, muss aber nicht einer Klasse zugeschrieben werden
|
||||
- : ContentManagementSystem - Klasse ist bekannt, muss aber keinen Namen haben
|
||||
- admin : Administrator - Klasse und Name sind bekannt
|
||||
- eventHandlers[2] : EventHandler - Teil innerhalb Array und bekannte Klasse
|
||||
|
||||
## Messages
|
||||
- Mit einem Pfeil spezifiziert
|
||||
- 
|
||||
|
||||
### Message Signatures
|
||||
- Format für eine Signatur:
|
||||
- _attribute = sinal_or_message_name (arguments) : return_type_
|
||||
- abhängig von den Informationen die bekannt sind, ggf auch kürzer
|
||||
|
||||
## Activation Bars
|
||||
Indizieren, dass ein [Teilnehmer](UMLSequenzDiagramme.md#participants) aktiv ist
|
||||
|
||||
|
||||
|
||||
## Nested Messages
|
||||
- [Nachricht](#messages) von einem [Teilnehmer](#participants) resultiert in weitere Nachrichten, welcher der Empfänger schickt
|
||||
- Diese neuen Nachrichten werden als "nested" innerhalb der triggernden Nachricht bezeichnet
|
||||
- 
|
||||
- Bspw.:
|
||||
- participant1 sends initialMessage() to p2
|
||||
- When p2 receives initialMessage(), p2 becomes active, sends two nested messages to p3
|
||||
|
||||
## Message Types
|
||||
### Message Arrows
|
||||
|
||||
|
||||
#### Creation and Destruction
|
||||
- Nicht alle Teilnehmer leben während der gesamten Sequenz
|
||||
|
||||
|
||||
|
||||
### Creation of Participants
|
||||
- create() Nachricht zu der Lebenslinie
|
||||
- **Nutzung der "dropped participant box"**
|
||||
- macht es klar, dass der Teilnehmer vorher nicht existiert
|
||||
|
||||
### Destruction of Participants
|
||||
- Beendung der Lebenslinie mit dem Löschen-Kreuz
|
||||
|
||||
### Synchronous Messages
|
||||
- Default
|
||||
- Nachrichtensender wartet auf Antwort von Empfänger
|
||||
|
||||
### Return Message
|
||||
- Zeigt, dass die Kontroller der Aktivierung wieder zum Empfänger zurückgeht
|
||||
|
||||
### Asynchronous Message
|
||||
- _wird von uns nicht innerhalb des Systems genutzt_
|
||||
- _nur von Mensch zu System_
|
||||
- Sender wartet nicht bis der Empfänger fertig ist
|
||||
- Implementierung bspw. durch Threads
|
||||
|
||||
## Möglicher Spicker
|
||||
|
||||
|
||||
99
Writerside/topics/02/OOAD/UMLStateDiagramme.md
Normal file
99
Writerside/topics/02/OOAD/UMLStateDiagramme.md
Normal file
@ -0,0 +1,99 @@
|
||||
# State Machine Diagrams
|
||||
## Introduction
|
||||
- Beschreiben den Zustand von Objekten oder des Systems
|
||||
|
||||
### Introduction Example
|
||||
- Light can be on / off
|
||||
- 
|
||||
|
||||
## States
|
||||
- Diskretes, durchgehendes Segment von Zeit, während der das Verhalten des Objekts stabil ist
|
||||
- Kann eine passive Qualität haben
|
||||
- _Licht an / aus_
|
||||
- Kann auch eine aktive Qualität haben / Was das Objekt tut
|
||||
- _Kaffeemaschine mahlt Kaffee_
|
||||
- Objekt bleibt in dem Zustand bis es von einem Event stimuliert wird
|
||||
|
||||
- States sind **nicht**:
|
||||
- Objekte oder Komponenten des Systems
|
||||
- Aktivitäten des Systems
|
||||
|
||||
### Internal Activities of States
|
||||
|
||||
- 3 Aktivitäten die an einem definierten Moment ausgeführt werden
|
||||
- **entry behavior**
|
||||
- **do-activity behavior**
|
||||
- kann unterbrochen werden
|
||||
- **exit behavior**
|
||||
- entry- und exit behavior können nicht unterbrochen werden
|
||||
|
||||
#### Activities Example
|
||||
|
||||
|
||||
### Internal Pseudostate
|
||||
|
||||
- **nur einmalig**
|
||||
- Markieren den Start eines Maschinen-Diagramms
|
||||
- Keine eingehenden Pfeile
|
||||
- Ein ausgehender Pfeil zum ersten _richtigen_ Zustand
|
||||
- ohne Events
|
||||
|
||||
### Final State
|
||||
|
||||
- **können mehrere existieren**
|
||||
- Objekte können permanent in einem End-Status sein
|
||||
|
||||
|
||||
## State Transitions
|
||||
### External Transitions
|
||||
|
||||
- Repräsentiert eine Änderung des Zustands von einem Ursprungs-Zustand zu einem Ziel-Zustand
|
||||
- Eine Transition braucht keine Zeit
|
||||
- Das System ist immer in einem Zustand, nie in einer Transition
|
||||
|
||||
|
||||
|
||||
#### Syntax of Description: trigger[guard] / behavior
|
||||
- Alles **optional**:
|
||||
- **Trigger** (Event), dass eine [Transition](#state-transitions) hervorruft
|
||||
- **Guard** (Condition), welche die Ausführung der Transition aktiviert
|
||||
- Sobald das Event stattfindet, muss der Guard erfüllt werden
|
||||
- Falls dasselbe Event mehrere Transitions eines einzigen States hervorruft
|
||||
- Die Guards müssen sich gegenseitig ausschließen
|
||||
- Falls nicht: EIne Transition wird zufällig ausgesucht
|
||||
- **Behavior** (Effects) wird während der Transition ausgeführt
|
||||
|
||||
### Internal Transition
|
||||
- Handhaben Events innerhalb eines States
|
||||
- 
|
||||
|
||||
## Types of Events
|
||||
### Call Events
|
||||
- Operation calls inklusive der Parameter
|
||||
- _occupy(user, LectureHall)_
|
||||
|
||||
### Time Events
|
||||
- Zeitbasierter Zustandsübergang (relativ / absolut)
|
||||
- _relative: after(5 sec)_
|
||||
- _absolute: when(time == 16:00)_
|
||||
|
||||
### Change Events
|
||||
- Permanente Überwachung, ob eine Bedingung wahr wird
|
||||
- _when (registration == numberOfSeats)_
|
||||
|
||||
### Any Receive Events
|
||||
- Zur Spezifikation einen Typ eines _else_ Übergangs
|
||||
- Falls ein Event auftritt, welches keine Übergänge für den aktiven Zustand auslöst
|
||||
- _the object transitions to S4 without any event that is not e1 or e2_
|
||||
|
||||
### Completion Events
|
||||
- Falls alle Verhaltensweisen eines States vollständig sind
|
||||
- _once A1 is completed completion event triggers transition to S2_
|
||||
|
||||
## State Transition Examples
|
||||
- 
|
||||
- 
|
||||
- 
|
||||
|
||||
## Möglicher Spicker
|
||||
|
||||
Reference in New Issue
Block a user