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 > Blick ins [Repository](https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022projekt) --- # 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
--- # Warum ist Softwarearchitektur notwendig?  _(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_ --- # 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 --- # Projekt: Praktische Umsetzung * Klassendiagramm als Ausgangslage * Identifikation möglicher Komponenten * Pattern: (Abstract) Factory > Blick ins [Repository](https://gitlab.mi.hdm-stuttgart.de/jordine/se3sose2022projekt) --- # 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