Die Architecture-Tradeoff-Analysis-Method (ATAM) im Detail Kay Schützler

Gliederung Einleitung Beteiligte Personen Ergebnisse der ATAM Phasen der ATAM Zusammenfassung

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

Beteiligte Personen Das Evaluationsteam Projekt-Entscheidungsträger 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.

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 Team Leader: stellt Team zusammen; achtet auf Fertigstellung des Evaluations-Reports Evaluation Leader: sicher vor Publikum Scenario Scribe: Gute Handschrift; fähig Diskussionskernpunkte zu erkennen

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

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

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

Phasen der ATAM

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

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

Phasen der ATAM: Phase 3 Teaminterne Auswertung der Evaluation Erfolge, Misserfolge Bericht des Process Observers Aufwandsprotokollierung Überprüfung der Langzeiteffekte beim Klienten

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

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

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),...)

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

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

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

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

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.