Architektur Deep Dive

Von Anforderungen zu Entscheidungen und strukturiertem Code

Warum Architektur?

Software bleibt bestehen - unverändert

Aber die Welt verändert sich, mit ihren Anforderungen

-> Ständiges Anpassen notwendig

Warum Architektur?

• Unvermeidbare Basis jeder Software
• Frühzeitige Fehlererkennung durch geplante Strukturen
• Vermeidung von unkontrollierbarer Legacy-Software
• kontinuierliche Anpassung

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

=> Architektur begleitet die Software von Anfang bis Ende

Warum Architektur?

Haus der Geschichte, Darmstadt

Internetfund, toter Vogel

Warum Architektur?

• Architektur-Ziele: eher langfristig
• Projekt-Ziele: eher kurzfristig

=> möglichst große Schnittmenge aushandeln

Methoden zur Architekturgestaltung

Wo fängt man an?

Wie startet man?

Was soll dokumentiert werden?

Definition Softwarearchitektur

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

nach Mark Richards

Definition Softwarearchitektur

”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.”

nach ISO 42010

Grundelemente

• Unabhängige Bausteine
• Beziehungen/Relationen über definierte Schnittstellen
• Konzepte und Prinzipien

Definition Baustein

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

Kontext

Abhängigkeit: wie externe Faktoren Architekturentscheidungen beeinflussen

• Anpassung an Geschäftsziele und -umfeld
• rechtliche und technische Rahmenbedingungen
• organisatorische Faktoren
• Balancierung konkurrierender Projektfaktoren
• Regel: Es gibt kein Patentrezept

Fundament der Architektur

1. Bausteine und deren Zerlegung
2. Beziehungen zwischen Elementen und Umgebung
3. Grundsätze über Design und Entwicklung
4. Entscheidungen über Entwurf des Systems
5. Evolution des Systems unterstützen

Festhalten von Zielen

Schlecht: Implizite Aussagen/Wünsche werden oft vergessen

Gut: explizit ausarbeiten und aufschreiben

• Sichert Konsistenz bei Entscheidungen
• Schnelles Aufdecken von Konflikten
• Fördert Abstimmen und Festlegen mit Stakeholdern
• Zeigt auch Abwägung/Diskussion auf

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 von außerhalb des Teams
• Niemand benannt: Implizite Architektur aus dem Team
• Agenten: Themen explizit im Team verteilt
• im Team: Architekt unterstützt Team

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

Stakeholder

Def. Stakeholder

Personen oder Organisationen, welche

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

Und verschiedenste Anforderungen mitbringen:

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

Die Stakeholder-Prio-Matrix

Die Stakeholder-Prio-Matrix

begleitend zur Matrix eine übersichtliche Tabelle

Beispiel:

Anforderungen

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

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

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

Def. Qualität

Qualität: Ist == Soll

”… eine Eigenschaft einer Software, die sich bei Erstellung, Benutzung oder Weiterentwicklung zeigt.” nach Stefan Toth

ISO/IEC 25010 Qualitätsmodell

Externe und Interne Software-Qualität

1. Functional SuitabilityFunctional completeness, Functional correctness, Functional appropriateness
2. Efficiency / PerformanceTime behavior, Resource utilization, Capacity
3. CompatibilityCo-existence, Interoperability
4. UsabilityLearnability, Operability, Recognizability, Accessibility, User interface aesthetics
5. ReliabilityMaturity, Fault tolerance, Recoverability, Availability
6. SecurityConfidentiality, Integrity, Non-repudiation, Authenticity, Accountability
7. MaintainabilityAnalyzability, Modifiability, Testability, Modularity, Reusability
8. PortabilityAdaptability, Installability, Replaceability

Hilfestellung ISO25010 und Qualitätsbaum

Arc42 Quality

quality.arc42.org

Architectural Significant Requirements

1. Anforderungen erörtern
2. funktionale Anforderungen (aus)sortieren und priorisieren; Markieren mit “A”
3. Randbedingungen feststellen/festlegen; Markieren mit “R”
4. Qualitätsanforderungen aus mind. einer Anforderung und/oder Randbedinung; Markieren mit “Q”
5. optional: Nicht-Anforderungen; Markieren mit “N”

Architectural Significant Requirements

Beispiel

Kohäsion

Kohäsionskriterien

Clustern der ASR nach Kriterium

• Funktion
• Eigenschaft
• Inhalt
• Services
• …

keine Kriterien mischen!

Kohäsionskriterien

Beispiel

Black & White Box

Kontext Abgrenzen

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

=> Es kommt drauf an

Black Box

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

White Box

Aus dem gebildeten Konzept ergeben sich Brenn- und Schnittpunkte

• Zusammenhang Kohäsion ⇄ Loose Coupling
• Kohäsions-Levels erkennen & optimieren
• Einfluss auf Modularisierung beurteilen

Architektur Entscheidungen

Architecture Decision Record

• in Architektur dreht sich alles um Entscheidungen
• Entscheidungen diskutieren und mit Anforderungen abgleichen
• Entscheidungen systematisch festhalten
• Regel: Kill your Darlings

Architecture Decision Record

Grundlegender Aufbau:

Architecture Decision Record

Beispiel 1/3:

Architecture Decision Record

Beispiel 2/3:

Architecture Decision Record

Beispiel 3/3:

Agile Architektur

Dokumentation

• Klarheit und Konsistenz
• Anpassung an die Bedürfnisse verschiedener Stakeholder
• Wartung der Dokumentation als Teil des Entwicklungsprozesses

Regeln:

• Angemessenheit
• Korrektheit
• Wartbarkeit
• Verständlichkeit

Arc42

Cards42

Blickrichtung ändern, neue Wege und Lösungen finden

Roadmap.sh

Guter Startpunkt, mehr technische Anforderungen & Verständnis

Quellen & mehr

• WieErWill.dev
• iSAQB.org
• Roadmap.sh
• INNOQ.com
• Arc42.org
• Cards42.org
• DrawIO.com

Zeit für eure Fragen
& Diskussionen

WieErWill.dev/vcard.vcf