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– 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

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.