![Page 1: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/1.jpg)
Die Architecture-Tradeoff-Analysis-Method (ATAM) im Detail
Kay Schützler
![Page 2: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/2.jpg)
Gliederung
Einleitung Beteiligte Personen Ergebnisse der ATAM Phasen der ATAM Zusammenfassung
![Page 3: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/3.jpg)
Einleitung
ATAM: umfassende Methode zur Evaluation von Software-Architekturen
Verbindung von Geschäftszielen mit den dafür entscheidenden Architekturteilen
Abwägung von Kompromissen zwischen einzelnen Qualitätszielen
![Page 4: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/4.jpg)
Beteiligte Personen
Das Evaluationsteam– Projektexterne 3- bis 5-köpfige Gruppe mit
spezieller Rollenverteilung Projekt-Entscheidungsträger
– Projektvertreter mit Änderungsbefugnissen– Software-Architekt (!), Projektleiter, Kundenvertreter
Architektur-Interessenten– Inkl. Entwickler, Tester, Integratoren,
Wartungsverantwortliche, Nutzer, Entwickler anderer abhängiger Systeme u.a.
![Page 5: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/5.jpg)
Beteiligte Personen:Rollen im Evaluationsteam (1)
Team Leader– Organisation der Evaluation, Koordination mit dem Klienten,
Vertragserstellung, ... Evaluation Leader
– Durchführung der Evaluation, Unterstützung bei Szenariofindung, –priorisierung und –bewertung
Scenario Scribe– Dokumentation der Szenarien während ihrer Ermittlung,
Sicherung gemeinsamer Bezeichnungen Proceedings Scribe
– Elektronische Erfassung von Szenarien, ihrer Motivation und architekturellen Bedeutung, Erstellung von Szenario-Handouts
![Page 6: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/6.jpg)
Beteiligte Personen:Rollen im Evaluationsteam (2)
Timekeeper– Sicherstellung der Zeiteinhaltung
Process Observer– Dokumentation möglicher Verbesserungen des
Evaluationsprozesses, Erstellung eines Erfahrungsberichts nach der Evaluation
Process Enforcer– Diskret unterstützende Kontrolle des Evaluation Leaders,
Sicherstellung korrekter Prozessabläufe Questioner
– Vermeidung von Betriebsblindheit
![Page 7: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/7.jpg)
Ergebnisse der ATAM (1)
Eine übersichtliche Darstellung der Architektur– Präsentierbar in einer Stunde
Darlegung der Geschäftsziele– Oft erster Kontakt der Entwickler mit diesen Zielen
Qualitätsanforderungen als Sammlung von Szenarien– Geschäftsziele Qualitätsanforderungen
Zuordnung von Architekturentscheidungen zu Qualitätsanforderungen
![Page 8: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/8.jpg)
Ergebnisse der ATAM (2)
Eine Menge von erkannten „sensitivity“ und „tradeoff points“
– Architekturentscheidungen mit Effekten bezüglich eines (sensitivity point) oder mehrerer (tradeoff point) Qualitätsattribute
Eine Menge von Risiken und Nicht-Risiken– Risiko: Architekturentscheidung mit potenziellen
unerwünschten Konsequenzen bezüglich der Qualitätsanforderungen
Eine Menge von Risiko-Themen– Thematische Zusammenfassung systematischer Risiken
![Page 9: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/9.jpg)
Phasen der ATAM
![Page 10: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/10.jpg)
Phasen der ATAM: Phase 0
Gegenseitiges Kennenlernen– Einführung des Evaluationsteams in das Projekt– Einigung über logistische Aufgaben– Erledigung von Formalitäten
Erstinformation (und Unterstützung) des Projektleiters und des Software-Architekten bezüglich ihrer Aufgaben bei der Evaluation
![Page 11: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/11.jpg)
Phasen der ATAM: Phasen 1 und 2
Eigentliche Evaluationsphasen Ein Treffen mit den Entscheidungsträgern
– Erste Analysen Ein weiteres Treffen nach etwas zeitlichem
Abstand mit den Entscheidungsträgern und den Architektur-Interessenten– Weitergehende Analysen
Unterteilung in Schritte:– Phase 1: Schritte 1 – 6, Phase 2: Schritte 7 – 9
![Page 12: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/12.jpg)
Phasen der ATAM: Phase 3
Teaminterne Auswertung der Evaluation– Erfolge, Misserfolge– Bericht des Process Observers– Aufwandsprotokollierung
Überprüfung der Langzeiteffekte beim Klienten
![Page 13: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/13.jpg)
Einzelne Schritte der Evaluationsphasen (1)
Schritt 1 – Präsentation der ATAM:– Erläuterung des Prozesses, Fragenklärung, ...
Schritt 2 – Präsentation der „Business drivers“– Wichtigste Systemfunktionen– Alle relevanten technischen, konzeptionellen,
ökonomischen und politischen Bedingungen– Haupt-Interessenshalter der Architektur– Hauptsächliche architekturbeeinflussende
Qualitätsziele
![Page 14: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/14.jpg)
Einzelne Schritte der Evaluationsphasen (2)
Schritt 3 – Präsentation der Architektur– Aufgabe des Software-Architekten– Briefing des Architekten sehr empfehlenswert– Unterstützender Template-Einsatz günstig
Schritt 4 – Identifikation von Architekturansätzen– Patterns, styles, strategies, ...
![Page 15: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/15.jpg)
![Page 16: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/16.jpg)
Einzelne Schritte der Evaluationsphasen (3)
Schritt 5 – Erstellung des „Quality Attribute Utility Tree“– Ermittlung der entscheidenden Qualitätsattribute– Definition der Attribute über Szenarien– Priorisierung der Szenarien:
Allgemeine Wichtigkeit eines Szenarios (H/M/L) Schwierigkeit eines Szenarios bezüglich seiner
Umsetzbarkeit in der untersuchten Architektur (H/M/L) Szenarien mit Prioritätspaaren ((H,H), (H,M),(M,L),...)
![Page 17: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/17.jpg)
Einzelne Schritte der Evaluationsphasen (4)
Schritt 6 – Analyse der Architektur-Ansätze– Diskussion der höchstpriorisierten Szenarien
bezüglich ihrer Umsetzbarkeit mit der zu untersuchenden Architektur
– Ermittlung von sensitivity und tradeoff points und Charakterisierung dieser als Risiken/Nicht-Risiken
Ruhephase
![Page 18: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/18.jpg)
Einzelne Schritte der Evaluationsphasen (5)
Zweites Treffen in größerem Rahmen Schritt 7 – Szenario-Brainstorming und –
Priorisierung– Bewertung (und Ergänzung) des Utility Trees aus
Sicht der Interessenshalter– Priorisierung mittels Abstimmung (Stimmenzahl pro
Teilnehmer == 30% der Szenarienzahl)
Schritt 8 – Analyse der Architekturansätze– Analog zu Schritt 6
![Page 19: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/19.jpg)
Einzelne Schritte der Evaluationsphasen (6)
Schritt 9 – Präsentation der Resultate– Dokumentierte Architekturansätze– Szenarienmenge und ihre Priorisierung aus dem
Brainstorming– Utility Tree– Entdeckte Risiken– Festgehaltene Nicht-Risiken– Gefundene sensitivity und tradeoff points– Risiko-Themen
![Page 20: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/20.jpg)
Zusammenfassung
Die ATAM – ist keine Evaluation der Anforderungen– ist keine Code-Evaluation– umfasst keinen tatsächlichen Systemtest– ist kein präzises Instrument, aber identifiziert potenzielle
Risikobereiche in einer Architektur– ist eine robuste Methode – zwingt Entscheidungsträger und Interessenshalter zu präziser
Darstellung der Qualitätsanforderungen– zeigt die bezüglich der Szenario-Umsetzung relevanten
Architekturentscheidungen auf
![Page 21: Die Architecture-Tradeoff- Analysis-Method (ATAM) im Detail Kay Schützler](https://reader035.vdokument.com/reader035/viewer/2022062318/55204d6249795902118b68b6/html5/thumbnails/21.jpg)
Literatur
Clements, P.; Kazman, R.; Klein, M.: Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley, 2002. (Referenziert als [Clements02a])
Bass, L.; Clements, P.; Kazman, R.: Software Architecture in Practice, 2nd ed., Addison-Wesley, 2003.