Software

Architektur

Workshop

Vorstellungsrunde

Who?

Work?

Plan B?

Note: 🕘 09:00 – 09:15

• Ziel: Kennenlernen, Erwartungen klären
• Materialien: Namensschilder, Flipchart, Moderationskarten

Überblick

1. Grundlagen & Definitionen
2. Architecture Kata
3. Requirements Engineering
4. Qualitätsmerkmale & Kohäsion
5. Architekturentscheidungen mit ADR
6. Black-/White-Box-Sichten
7. Dokumentation mit arc42

Grundlagen & Definitionen

Warum Architektur?

Software bleibt bestehen - unverändert Die Welt verändert sich aber, mit ihren Anforderungen -> Ständiges Anpassen notwendig

Ziel guter Architektur

Software lange in angemessener Qualität, Zeit und Kosten weiter entwicklen

Architektur begleitet die Software von Anfang bis Ende

Verschiedene Ziele

Architektur-Ziele: eher langfristig

Projekt-Ziele: eher kurzfristig

=> möglichst große Schnittmenge aushandeln

Festhalten von Zielen

Schlecht: Implizite Aussagen/Wünsche oft vergessen

Gut: explizit ausarbeiten und aufschreiben

• sichert Konsistenz bei Entscheidungen
• Fördert Abstimmen und Festlegen mit Stakeholdern
• Zeigt auf Abwägung/Diskussion dar

Definition “Softwarearchitektur”

nach ISO 42010

“Die grundsätzliche Organisation eines Systems, wie sie sich in dessen Komponenten, deren Beziehung zueinander und zur Umgebung widerspiegelt, sowie die Prinzipien, die für seinen Entwurf und seine Evolution gelten.”

Definition “Softwarearchitektur”

nach Mark Richards

“Software Architecture is the stuff you can’t google.”

Was macht ein Software Architekt?

Mitarbeit in allen Phasen und Lebens-abschnitten des Software Systems

• Anforderungen analysieren
• Strukturen entwerfen
• Querschnittskonzepte schneiden
• Architektur kommunizieren
• Architektur bewerten
• Umsetzung begleiten

Aufgabenverteilung

• Klassisch: Architekt bestimmt außerhalb des Teams
• Niemand benannt: Implizite Architektur aus dem Team
• Agenten: Themen explizit im Team verteilt
• im Team: Architekt unterstützt Team

Fundament der Architektur

• Bausteine und deren Zerlegung
• Beziehungen zwischen Elementen und Umgebung
• Grundsätze über Design und Entwicklung
• Entscheidungen über Entwurf des Systems
• Evolution des Systems unterstützen

Def: Baustein

• ein einzelnes Element des Systems
• in sich gekapseltes Verhalten
• Schnittstellen zu anderen Bausteinen
• austauschbar und wiederverwendbar

Komplexität in Software

beherrschbar machen durch iteratives Vorgehen -> Iterativ entwickeln und adaptieren -> inkrementell wachsen -> Ideen auch mal ausprobieren -> Frühzeitige Rückmeldung durch Stakeholder -> kontinuierliche Anpassung -> schnelles Erkennen von Risiken

Architecture Kata & Canvas

Architecture Kata

Architekturen erstellen benötigt Übung inspiriert von jap. Kampfkünsten sind Katas zur ständigen Verbesserung Trainingsmethode für Architekten und agile Teams für Umsetzung von Anforderungen in passende Architektur

Ablauf einer Kata

• 3-5 Personen pro Gruppe
• Problemstellung in Gruppe verteilen
• Gruppen erstellen und skizzieren schrittweise Softwarearchitektur
• 20-45 Minuten je Abschnitt + ~15 Min Feedback mit anderen Gruppen
• Hilfestellung und roter Faden durch Canvas

Architektur Canvas

architecture-canvas.png

☕️ 10:15 – 10:30 Pause

Requirements Engineering

Anforderungen

• oftmals nur eine erste Idee
• Software soll diese Ideen umsetzten
• Schwammige Ideen lassen sich technisch nicht umsetzten
• -> genauere Analyse notwendig

Stakeholder

Personen oder Organisationen, welche

• das System nutzen, betreiben, prüfen, entwickeln, zahlen,…
• Daten liefern oder empfangen
• Interesse am System/Betrieb/Resultaten… haben

Stakeholder

• Wer nimmt Einfluss bzw. Wer ist betroffen?
• Was sind die Erwartungen?
• Wie groß ist der Einfluss (worauf)?
• Wo können Konflikte entstehen?

Stakeholder Prorisierungsmatrix

Stakeholder Tabelle

| Rolle | Beschreibung | Ziel | Kontakt | Prio | Info-Bedarf | | --------- | ------------- | --------------- | ------- | ------ | ----------------- | | Betreiber | Rechenzentrum | Auftraggeber | … | Hoch | Betriebs-Handbuch | | Endkunde | Kunde | Produkte kaufen | - | Hoch | - | | Partner | Versand,… | Import/Export | … | Mittel | Spez. Export | | … |

Anforderungen verstehen

1. Anforderungen sammeln
2. aufräumen und bereinigen
3. angemessenen Umfang sicherstellen
4. Widersprüche beseitigen

Anforderungen klären

• Stakeholder und ihr Ziel identifizieren
• Kontext/Scope abgrenzen
• Funktionen/Prozesse/Abläufe verstehen
• Qualitätsziele erstellen
• Randbedingungen festlegen

verschiedene Anforderungen

• Funktionale Anforderungen: Was soll das System tun?
• Qualitätsanforderung: Wie soll ein System etwas tun?
• Randbedingungen: Welche Einschränkungen liegen vor?
• Nicht-Anforderungen: Was soll aktiv nicht gemacht werden?

Note: 🕥 10:30 – 11:00

• Inhalt:
  • Stakeholder-Analyse, Anforderungsarten (funktional, nicht-funktional)
  • Qualitätsmerkmale (Reliability, Maintainability, Security…)
• Lernziele:
  • Anforderungen systematisch erfassen & priorisieren
  • Qualitätsszenarien formulieren

Funktionale Anforderung

Was muss die Anwendung können? Welche Funktionen erfüllen?

z.B. Zeit anzeigen, Rechenaufgabe lösen, …

Randbedingungen

Auf diese Bedingungen ist nur wenig Einfluss möglich Freiheitsgrad der Architektur durch Randbedinungen eingeschränkt Man kann sich aber entsprechend darauf einstellen

z.B. Hardware, Budget, Compliance,…

Nicht-Anforderungen

Es gibt bestimmte Dinge, die explizit nicht getan werden sollen Durch die Definition von Nicht-Anforderungen, kann das System einfacher gestaltet werden Eine spätere Änderung ist meist schwer

z.B. keine Nutzerdaten speichern

Übung: Stakeholder & Requirements auf Kata anwenden

Ziel:

1. Priorisierte Liste von Stakeholdern
2. Top-3-Funktionale Anforderungen
3. Randbedingungen
4. Nicht-Anforderungen

Note: 🕚 11:00 – 11:30

Einführung Qualitätsmerkmale & Kohäsion

Qualität

Qualität: Ist == Soll

… eine Eigenschaft einer Software, die sich bei Erstellung, Benutzung oder Weiterentwicklung zeigt.

Stefan Toth

ISO/IEC 25010 Qualitätsmodell

Externe und Interne Software-Qualität

| Quality Characteristic | Subcharacteristics | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Functional Suitability | - Functional completeness
- Functional correctness
- Functional appropriateness | | Efficiency / Performance | - Time behavior
- Resource utilization
- Capacity | | Compatibility | - Co-existence
- Interoperability | | Usability | - Learnability
- Operability
- Appropriateness recognizability
- Accessibility
- User error protection
- User interface aesthetics | | Reliability | - Maturity
- Fault tolerance
- Recoverability
- Availability | | Security | - Confidentiality
- Integrity
- Non-repudiation
- Authenticity
- Accountability | | Maintainability | - Analyzability
- Modifiability
- Testability
- Modularity
- Reusability | | Portability | - Adaptability
- Installability
- Replaceability |

Arc42 Quality

quality.arc42.org

screenshot

Arten von Qualitätsszenarien

• Verwendung/Use Case: normales arbeiten am System
• Änderung/Growth: Zukünftige Änderungen
• Stress/Exploratory: Unerwartetes passiert mit System/Umgebung

Kontext Abgrenzen

• Was liegt im System und was außen?
• was steht im Fokus
• welches Bauteil ist wofür?

=> Es kommt drauf an

Kontext Abgrenzen

• das System von außen
• Schnittstellen zur Umgebung
• wichtigesten Anwendungsfälle (fachlich)
• technische Umgebung

Kontext und Kohäsion

Aus dem gebildeten Konzept ergeben sich Brenn- und Schnittpunkte

Note: 🕦 11:30 – 12:00

• Inhalt:
  • Qualitätsattribute
  • Cohesion: Grad der in-Module-Zusammengehörigkeit
• Lernziele:
  • Bedeutung von hoher Kohäsion für Wartbarkeit, Verständlichkeit, Wiederverwendbarkeit verstehen
• Materialien: Qualitätsszenario-Beispiele, UML-Schaubilder

🍽️ 12:00 – 13:00 Mittagspause

Deep Dive: Kohäsion & Kopplung

Note: 🕐 13:00 – 13:45

• Inhalt:
  • Typen von Kohäsion (funktional, sequentiell, kommunikativ…)
  • Zusammenhang Kohäsion ⇄ Loose Coupling
• Lernziele:
  • Kohäsions-Levels erkennen & optimieren
  • Einfluss auf Modularisierung beurteilen
• Materialien: Code-Snippets, Grafik „Cohesion vs. Coupling“

Architekturentscheidungen (ADR)

Umgang mit Konflikten

• Anforderungen und Qualitäten beeinflussen sich teils gegenseitig
• Ziele müssen priorisiert werden
• Priorisierung anhand von Geschäftszielen

Note: 🕜 13:45 – 14:15

• Inhalt:
  • ADR-Template: Title, Context, Decision, Consequences
  • Best Practices (Versionierung, Log)
• Lernziele:
  • Wichtige Entscheidungen dokumentieren & nachvollziehbar machen
• Materialien: ADR-Markdown-Vorlage

Black-Box & White-Box Sichten

Note: 🕑 14:15 – 14:30

• Inhalt:
  • Black-Box-View: System als Ganzes, externe Schnittstellen
  • White-Box-View: innere Bausteine, Interaktionen
• Lernziele:
  • Unterschiedliche Blickwinkel auf Architektur anwenden
• Materialien: UML Component Diagram, SysML-WhiteBox-Beispiel

☕️ 14:30 – 14:45 kurze Pause

Übung: Kohäsion & Black/White-Box auf Kata

Ziel

• Hohe Kohäsion in Modulen
• Black-Box-View erstellen
• White-Box-Details ergänzen

Note: 🕓 14:45 – 15:15

Dokumentation mit arc42

Note: 🕔 15:15 – 15:45

• Inhalt:
  1. Introduction & Goals
  2. Constraints
  3. Context & Scope
  4. Solution Strategy
  5. Risks & Technical Debt
• Lernziele:
  • arc42-Template souverän einsetzen
  • Kritische Risiken und technische Schulden identifizieren
• Materialien: arc42-Shortguide, Beispiel-Doku

Übung: Doku mit Kata & Canvas, Risiken/Glossar

• Ziel: arc42 auf Kata anwenden
• Kurzdokumentation inkl. Glossar & Risiko-Matrix

Note: 🕔 15:45 – 16:00

Take Home

3 Punkte für die nahe Zukunft

Feedback

Lessons Learned?

Quellen

• isaqb.org
• cutter.com/article/blackbox-whitebox-principle-498606
• arc42.org
• req42.org

Zeit fuer eure Fragen // Diskussionen

VCARD:
/vcard.vcf

MAIL:
robert.jeutter@wieerwill.dev

WEB:
https://wieerwill.dev