Softwarearchitektur

class: center, middle, first

# Software-Entwicklung 3

## Softwarearchitektur

---

# Agenda

1. Recap
2. Warum Softwarearchitektur?
3. Grundfertigkeiten Softwarearchitekt:innen
4. Basisprinzipien
5. Praktische Umsetzung im Demo-Projekt

---

# Recap: Was haben wir letzte Woche besprochen?

* Grundlagen der Anforderungsanalyse
* Funktionale und Nicht-Funktionale Anforderungen
* Fachliche und technische Anforderungen
* Methoden zur Anforderungsanalyse
* Projektarbeit

---

# Recap: SE1 & SE2

## Was sind Ihre Erfahrungen mit Softwarearchitektur?

* Wie haben Sie Ihre Projekte organisiert?
* Was hat dabei gut funktioniert?
* Wo gab es Probleme?

---

# Beispiel: Lego Saturn V

<img src="img/softwarearchitektur/saturn_v_collage.jpg" width="80%"/>
---

# Warum ist Softwarearchitektur notwendig?

![Big Ball of Mud](img/softwarearchitektur/big_ball_of_mud.png)

_(nach "Software-Architektur", O. Vogel, I. Arnold et al., Springer, 2009)_

---

# Abhängigkeiten in Softwareprojekten

* Assoziation
* Komposition
* Aggregation
* Generalisierung/Spezialisierung
* Realisierung
---
# Warum ist Softwarearchitektur notwendig?

**Komplexität beherrschen**

* Softwareprojekte wartbar halten
* Softwareprojekte erweiterbar gestalten
* Softwareprojekte kommunizierbar machen
* Softwareprojekte planbar machen

---

# Was ist Softwarearchitektur?

* Grundstruktur eines Softwareprojekts
* Unterteilung der Bestandteile
* Beziehung zwischen den Bestandteile
* Gerüst auf dem Anforderungen umgesetzt werden

> Problem: Softwarearchitektur meistens nicht von "außen" ersichtlich.

---

# Grundfertigkeiten Softwarearchitekt:innen

* Generalisierung: Abstraktionsvermögen
* Zusammenhänge erkennen
* Muster kennen und erkennen
* Entwicklungserfahrung
* Spezialisierung: Zerlegung in Teilprobleme
* Erfahrungsschatz: Aus Erfolgen und Fehlern lernen
* Kommunikationsfähigkeit und zuhören können
* Implizites explizit machen

---

# Qualitätsmetriken

## Software Product Quality

_nach: "Software Product Quality", ISO/IEC 25010, https://iso25000.com/index.php/en/iso-25000-standards/iso-25010_

---
class: center, middle

# Architekturmuster

---
# Architekturmuster

* **Schichtbasierte Architektur**
* Pipeline Architektur
* **Microkernel Architektur**
* Servicebasierte Architektur
* Eventbasierte Architektur
* "Space-based" Architektur
* Service-orientierte Architektur (SOA)
* **Microservice-basierte Architektur**

_(nach: "Handbuch moderner Softwarearchitektur", M. Richards, N. Ford., O'Reilly, 2021)_

---
# Schichtbasierte Architektur

_(nach: "Handbuch moderner Softwarearchitektur", M. Richards, N. Ford., O'Reilly, 2021)_

---
# Microkernel Architektur

_(nach: "Handbuch moderner Softwarearchitektur", M. Richards, N. Ford., O'Reilly, 2021)_

---
# Microservice Architektur

_(nach: "Handbuch moderner Softwarearchitektur", M. Richards, N. Ford., O'Reilly, 2021)_

---
class: center, middle

# Umsetzen einer Architektur

---

# Basisprinzip: Modularisierung - Separation of Concerns

* Untergliederung in logische Module, Komponenten
* Austauschbarkeit
* Unabhängigkeit
* Herangehensweisen:
  * Top-Down ("Teile und Herrsche")
  * Bottom-up
  * Design to test (TDD)

---

# Basisprinzip: Klare Abhängigkeiten

* Wer kommuniziert mit wem?
* Wie ist die Kommunikationsrichtung zwischen Modulen?
* Identifikation von "stabilen" Komponenten: Zählen von eingehenden Abhängigkeiten.
* Wahrung von Austauschbarkeit
* **Bitte vermeiden**: Zirkuläre Abhängigkeiten

---

# Basisprinzip: Don't repeat yourself (DRY)

* Vermeidung von doppelten Code
* Erhöht die Wartbarkeit

---

# Basisprinzip: Priciple of least astonishment

* Verhalten einer Methode/Objekt/Modul darf nicht überraschen
* Benennungen und Parameter beschreiben genau was passiert

---

# Basisprinzip: CRUD

_hier: Betrachtung im Systemkontext_

* **Create**: Welches Modul ist für die Erzeugung von Daten verantwortlich? Wer sind die Auslöser?
* **Read**: Welches Modul ist für das Auslesen von Daten verantwortlich? Wer sind die Auslöser?
* **Update**: Welches Modul aktualisiert/ändert Daten? Wer sind die Auslöser?
* **Delete**: Welches Modul löscht Daten? Wer sind die Auslöser?

---

# Basisprinzip: Interfaces statt konkreter Implementierung

```java
// Variante 1
MyImplementation a = new MyImplementation();

// Variante 2
MyInterface a = new MyImplementation();
```

* Welche Variante ist besser? Warum?

---

# Basisprinzip: Single Responsibility Principle

* Jedes Modul/Klasse/Methode ist genau für eine Aufgabe verantwortlich

```java
// schlecht
public Person saveAndGetPerson(Person savePerson, int personId){ 
  // ...
}
```

```java
// besser
public void savePerson(Person savePerson){ 
  // ...
}
public Person getPerson(int personId){ 
  // ...
}
```

---

# Basisprinzip: Open Closed Principle

* Module sollen offen für Erweiterungen sein
* Module sollen geschlossen für Veränderungen sein

---
# ADR: Architecture Decision Records

Textuelle Beschreibung, die eine architektonische Entscheidung festhält.

## Grundstruktur (eine Möglichkeit)

* **Titel**: Nummerierung inkl. Kurzbeschreibung der architektonischen Entscheidung.
* **Status**: _Vorgeschlagen_, _Akzeptiert_, _Ersetzt durch <Nummer>_
* **Kontext**: Rahmenbedingungen, Situationen in denen die Entscheidungen zum Tragen kommt.
* **Entscheidung**: Entscheidung für ein Vorgehen inkl. Begründung.
* **Konsequenzen**: Auswirkungen der Entscheidungen.

_(nach: "Handbuch moderner Softwarearchitektur", M. Richards, N. Ford., O'Reilly, 2021)_

---

# ADR: Architecture Decision Records

## Beispiele
* [Timestamp Format](https://github.com/joelparkerhenderson/architecture-decision-record/tree/main/examples/timestamp-format)
* [Festlegung des DBMS](https://github.com/joelparkerhenderson/architecture-decision-record/tree/main/examples/mysql-database)
* [Festlegung der Programmiersprache](https://github.com/joelparkerhenderson/architecture-decision-record/tree/main/examples/programming-languages)
* [Weitere Beispiele](https://github.com/joelparkerhenderson/architecture-decision-record/tree/main/examples)

## Tools
* (GitLab) Wiki
* [ADR Tools](https://github.com/npryce/adr-tools)

---
# Projekt: Praktische Umsetzung

* Klassendiagramm als Ausgangslage
* Identifikation möglicher Komponenten
* Pattern: (Abstract) Factory
* ADR: Erstellen und pflegen der archetektonischen Entscheidungen

> Blick ins [Repository](https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2023projekt)

---
# Notes

* Umsetzen der Anforderungen in Code
* Einteilen in Packages
* Ggf. Java Modules
* Richtiges Maven Projekt wählen
* In einzeln deploybare Artefakten denken
* Stabile Teile im Code: Zählen von Abhängigkeiten
* Nach außen mit Interfaces kommunizieren
* (Abstract) Factory
* Issues mit Code verlinken

---
# Weitere Informationen

* "Handbuch moderner Softwarearchitektur", M. Richards, N. Ford., O'Reilly, 2021
* "Software-Architektur", O. Vogel, I. Arnold et al., Springer, 2009
* "software-architektur.tv", wöchentlicher Podcast, https://software-architektur.tv bzw. https://www.youtube.com/@EberhardWolff
* Software Architecture (Reddit), https://www.reddit.com/r/softwarearchitecture/
* "A Simple Framework for Architectural Decisions", https://www.infoq.com/articles/framework-architectural-decisions/
* "Using architectural decision records to streamline technical decision-making for a software development project", https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/welcome.html
* "Architecture decision record (ADR)", https://github.com/joelparkerhenderson/architecture-decision-record