ATAM - User Websites on enterpriselab.ch

Kapitel 1
Applikations-Architektur VII
Software Architecture, Quality & Testing
FS 2016
Prof. Dr. Jana Koehler
[email protected]
© HSLU - JK
Agenda
Bewertung von Architekturen mit der ATAM Methode
Architecture Tradeoff Analysis Method (ATAM)
"There is no such thing as an inherently
good or bad architecture. Architectures are
either more or less fit for some purpose."
Bass, Clements, Katzman
2
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Wie komme ich zu einer guten Architektur
 Den Prozess des Entwurfs, des Prototyping, der Umsetzung
gut beherrschen
 Die Strukturen gut entwerfen
 Empfehlungen sind möglich, aber keine Rezepte
– "rules of thumb"
– Erfahrungen aus guten Projekten
– Sind Empfehlungen verletzt, besteht ein erhöhtes Risiko
einer schlechten Architektur
3
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Bewertung von Architekturen
 Ist die Architektur gut genug?
 Software Architektur kann nur qualitativ bewertet werden
– Keine sinnvollen Quantitäten direkt messbar
 Quantitative Messung möglich von
– Änderungsumfang und -häufigkeit der Anforderungen
– Testumfang und -abdeckung
– Fehlerbehebung während der Implementierung
– Codemetriken
 Liefern keine Antwort auf unsere Frage
 Aber wir haben Response Measures aus den Szenarien!
4
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Analyse als Voraussetzung der Bewertung
 Immer wenn eine Schlüssel-Entscheidung getroffen wird
oder ein Meilenstein erreicht wird, sollten die gewählte(n)
Entscheidungen und mögliche Alternativen analysiert
werden
– Wichtigkeit der Entscheidung
– Anzahl möglicher Alternativen
– "Gut genug" im Vergleich zu "Perfekt"
 Analysekosten sollten Kosten einer Fehlentscheidung nicht
übersteigen
 Gedankenexperimente, Simulationen, Prototypen
5
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
ATAM
 Evaluatoren müssen die Architektur nicht kennen
 Das System muss noch nicht existieren
 Es kann viele Stakeholder geben
 3 Gruppen von Beteiligten
1. Evaluatoren: ausserhalb des Projektes, ATAM Experten
2. Projektentscheider: Architekt, project manager, product owner
3. Architektur Stakeholder:
•
•
•
6
Haben ein Interesse an einer funktionierenden Architektur
Formulieren die Qualitätsattribute, die das System für sie zu einem
Erfolg machen (Entwickler, Tester, Benutzer)
12-15 bei grossen Systemen
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Geschäftsziele und
Rahmenbedingungen
Qualitätsbaum
(utility tree)
Funktionale und Nichtfunktionale
Anforderungen
Aktueller
Architektur-Entwurf
Szenarios
ATAM
Risiken und “Nicht-Risiken”
Sensible Punkte und Kompromisse
Risikoanalyse als Ziel
Einen Zusammenhang finden zwischen den Architekturentscheidungen und dem zu erwartenden Systemverhalten
7
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Ergebnisse von ATAM
1. Eine präzise und verständliche Darstellung der Architektur
– kann in einer Stunde präsentiert werden
2. Formulierung der Geschäftsziele
3. Priorisierte Anforderungen der Qualitätsattribute in Form
von Szenarien
4. Risiken
– Eine Architekturentscheidung, die negative Auswirkungen auf ein Szenario (das QA) hat, ist ein Risiko
– Architectural risk mitigation plan
8
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Ergebnisse von ATAM (Forts.)
5. Risikothemen: Welche systematischen Schwächen in der
Architektur (oder auch im Team oder im Prozess) führen zu
den Risiken?
6. Beziehung der Architekturentscheidungen zu den
Qualitätsattributen
– Welche Entscheidungen stützen welche Qualitäten?
7. Sensible Punkte und Kompromisse
– Architekturentscheidungen mit Auswirkungen auf ein
oder mehrere Qualitätsattribute
9
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
ATAM Qualitätsbaum (Utility Tree) – Qualitäten wichten
Szenarien
Qualitäten
COTS - Commercial Off The Shelf
L,H,M - Low, High, Medium
Intervalle: Auftrittswahrscheinlichkeit +Relevanz/Risiko (optional)
10
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Andere Variante Utility Tree
6
e
11
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Beispiel aus einer BDA
12
SAQT 2016- Software Architektur: Sichten, Dokumentation & Architekturentscheidungen
©
HSLU - JK
Beispiel aus einer BDA
13
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Beispiel aus einer BDA
14
SAQT 2016- Software Architektur: Sichten, Dokumentation & Architekturentscheidungen
©
HSLU - JK
Qualitäten
15




Performance
Availability
Usability
Security
Sicht des Benutzers




Maintainability
Portability
Reusability
Testability
Sicht des Entwicklers






Time To Market
Cost and Benefits
Projected life time
Targeted Market
Integration with Legacy System
Roll back Schedule
Sicht des Business
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Szenarien
 Kurze und präzise Beschreibung der Interaktion eines
Stakeholders mit dem System
– Vom Stimulus zu messbarer Systemreaktion
 Wichtig: alle Stakeholder einbeziehen
– Benutzer, Entwickler, Administratoren, …
 Stakeholder bewerten und wählen die wichtigsten Szenarien
(ca. 10-15)
16
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Typische Szenarien
 Erwartete Use cases mit Qualitätsattribut (Verfügbarkeit)
– "Remote User greift via Web auf die Report DB zu und
erwartet eine Systemantwort in weniger als 5 Sekunden."
 Zu erwartende Änderungen (growth scenarios)
– "Hinzufügen eines weiteren Portalservers innerhalb einer
Woche, um die Antwortzeiten auf unter 2.5 Sekunden zu
reduzieren."
 Kritische Stress-Situationen für das System
– "Die Hälfte der Server fällt im Betrieb aus, ohne die
Verfügbarkeit des Systems zu beeinträchtigen."
17
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Risiken und Nicht-Risiken (Risks/Non-Risks)
 Architekturentscheidungen, die ein Risiko (oder kein Risiko)
für ein gegebenes Qualitätsattribut sind
 Nicht-Risiken: "Gute" Entscheidungen, die ein
Qualitätsattribut stützen
 "Der Backup der Datenbank stellt ein Risiko für die
Performanz des Systems dar, wenn eine hohe
Systemleistung mit hohen Kosten verbunden ist."
 "Der Backup ist kein Risiko bei geringen Kosten für die
Systemleistung."
18
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Sensible Punkte und Kompromisse
 Sensible Punkte (Sensitivity Points)
– Architekturentscheidungen, die bei einer geringfügigen
Änderung grosse Auswirkungen auf ein Qualitätsattribut
haben
– "Der tägliche Backup der Datenbank ist wichtig für die
Zuverlässigkeit des Systems."
 Kompromisse (Tradeoffs)
– Architekturentscheidungen, die Auswirkungen auf
mehrere Qualitätsattribute haben
– "Der Backup der Datenbank sichert die Zuverlässigkeit,
aber beeinträchtigt die Performanz des Systems."
19
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Sensible Punkte und Risiken/Nichtrisiken
 Responses des Systems, die wir in den ArchitekturEntscheidungen auf der Annahme bestimmter Stimuli
definiert haben
– Ändern sich unsere Annahmen müssen wir unsere
Entscheidungen überprüfen, weil aus Nichtrisiken
(Stärken) Risiken (Schwächen) werden können und
umgekehrt
– Sensitivity points sind Eigenschaften kritischer
Komponenten (oder ihrer Beziehungen), die
entscheidend sind, damit ein bestimmter Response
erzeugt wird
20
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Beispiel: Shared File System
 wichtige gemeinsame Information verschiedener
Komponenten wird in einer Datei auf einem zentral
zugänglichen Server gespeichert
– die Datei ist klein
– keine Sicherheitsanforderungen
– kein simultaner Zugriff der Komponenten auf die Datei
möglich
 Sobald sich eine dieser Annahmen ändert, müssen wir
unsere Entscheidung revidieren
– das "flat file" kann jetzt zum Risiko werden
21
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Wie verläuft ATAM?
1. Stakeholder zusammenbringen
2. ATAM erklären
Ggf.
wiederholen
3. Business Driver/Kontext für Systementwicklung
zusammenfassen
4. Architektur vorstellen - Stile sind wichtig
5. Qualitätsbaum aufbauen
a) Attribute hierarchisieren und Bedeutung quantifizieren
b) Szenarien definieren und priorisieren
6. Szenarien und Architektur gegenüberstellen
7. Risiken, sensible Punkte, Kompromisse identifizieren
8. Massnahmen definieren
22
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Vorteile von ATAM
 Klärung von nichtfunktionalen Anforderungen und
Qualitätsattributen
 Verbesserte Dokumentation von Architektur und
Architekturentscheidungen
 Intensivierte Diskussion zwischen Stakeholdern
 Frühe Erkennung von Risiken, wenn früh durchgeführt
 RISIKO: ATAM ist zeitaufwendig!
 Gewünschtes Ergebnis
 Risk Mitigation - Einleitung von Massnahmen zur
Reduzierung der Risiken
 Verbesserte Architektur
23
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Light-weight ATAM
 Für kleinere und wenig riskante Projekte
 Internes kleineres Team
1.
ATAM erklären
2.
Business Driver/Kontext für Systementwicklung zusammenfassen (15 min)
3.
Architektur vorstellen (25 min)
4.
Qualitätsbaum aufbauen (Qualitätsbaum + Szenarien existieren, review in 1h)
a) Attribute hierarchisieren und Bedeutung quantifizieren
b) Szenarien definieren und priorisieren
5.
Szenarien und Architektur gegenüberstellen (2-3h)
6.
Risiken, sensible Punkte, Kompromisse identifizieren (in Schritt 5)
7.
Ergebnisse dokumentieren (0.5 h)
24
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Aufgabe K9: Architekturbewertung
I.
Erarbeiten Sie einen einfachen Qualitätsbaum mit ca. 3-5
Kriterien und 2-3 Szenarien für das Kolumbus Projekt.
II. Identifizieren Sie mindestens ein Risiko und einen
Kompromiss in Ihren Architekturentscheidungen.
25
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Zusammenfassung
 Nachlesen im Starke:
– Kapitel 9
 Besser erklärt in Clements, Kazman, Klein: Evaluating
Software Architectures
– Kapitel 2,3,4
 Szenarien als Grundlage der Bewertung
 Kein absolutes Qualitätsmass, sondern Kompromisse,
sensible Punkte und Risiken als Ergebnis
 Fördert das Denken in Entscheidungen und
Entscheidungsalternativen
 Prototypen als wichtige Grundlage, um zu echten
Messwerten zu kommen
26
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Arbeitsfragen
1. Worin bestehen die Herausforderungen beim
Architekturentwurf?
2. Nennen Sie Beispiele für Empfehlungen für den
Architekturentwurf.
3. Wann analysieren und bewerten Sie eine Architektur?
4. Womit können Sie Architekturen analysieren?
5. Womit können Sie Architekturen bewerten?
6. Erläutern Sie die Grundideen von ATAM.
7. Welche Rolle spielen Szenarien im ATAM Utility Tree?
8. Was verstehen wir in ATAM unter Risiken, Nicht-Risiken,
sensiblen Punkten und Kompromissen?
27
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK
Arbeitsfragen (Forts.)
9. Warum analysieren + dokumentieren wir welche
Architekturentscheidungen welche Qualitätsattribute
beeinflussen?
10. Was erhalten wir als Ergebnis von ATAM?
11. Worin sehen Sie Vorteile/Nachteile von ATAM?
12. Wie würden Sie ATAM verwenden, um 2 alternative
Architekturentwürfe miteinander zu vergleichen?
13. Sie sollen die Architektur eines Systems überprüfen. Der
Architekt ist nicht verfügbar und Sie dürfen auch nicht mit
Stakeholdern reden. Was machen Sie?
14. Wann wenden Sie ATAM voll oder lightweight an?
15. Was bekommen Sie von ATAM nicht?
28
SAQT 2016 - Software Architektur: ATAM
©
HSLU - JK