- Software Architecture Analysis Method
-
SAAM ist ein Akronym für "Software Architecture Analysis Method". Das Verfahren wurde von Rick Kazman, Gregory Abowd, Len Bass und Paul Clements entwickelt.
(Diese Abkürzung wird auch im militärischen Bereich für "Surface-to-Air Anti-missile" gebraucht.)
Inhaltsverzeichnis
Kurzbeschreibung SAAM
SAAM ist das als erste publizierte und eines der einfacheren Verfahren zu szenariobasierten Architekturbewertung. SAAM eignet sich zur Untersuchung von Softwarearchitekturen im Hinblick auf Qualitätsattribute (qualitative Anforderungen) wie
- Modifizierbarkeit, Portierbarkeit, Erweiterbarkeit, etc. (Haupteinsatzzweck)
- Performance, Verlässlichkeit, etc,
aber auch zur Evaluation des Funktionsumfangs (funktionale Anforderungen) einer Software(architektur). Grundsätzlich werden bei einer SAAM-Bewertung Szenarios erhoben, priorisiert und den von ihnen betroffenen Teilen der zu untersuchenden Softwarearchitektur zugeordnet. Bereits dies kann auf Probleme in der Architektur hindeuten:
- Problematisch sind eventuell Komponenten, auf die viele Szenarios zugeordnet wurden
- Problematisch sind eventuell Architekturentscheidungen, die dazu führen dass ein Szenario auf viele Komponenten zugeordnet wurde
Für die Änderungen, die an der Architektur für die jeweiligen Szenarios durchgeführt werden müssen, wird der Änderungsaufwand oder eine damit verbundene Größe geschätzt.
Der Prozess der Zuordnung von Szenarios auf Komponenten kann dabei auch zu einer Verbesserung der Architekturdokumentation führen. Die Bewertung beginnt mit einer schon vorhandenen Architekturdokumentation, ist für eine sinnvolle Zuordnung diese nicht ausreichend detailliert, werden entsprechende Teile der Architektur genauer dokumentiert.
Ein weiterer Vorteil einer SAAM-Bewertung besteht darin, dass sie die Kommunikation zwischen den Projektbeteiligten verbessert: Der Bewertungsprozess bringt die Projektbeteiligten in Meetings zusammen und ermöglicht ihnen, ihre Wünsche, Vorschläge und Kritikpunkte für die zukünftige Entwicklung des Systems miteinander zu diskutieren. Dabei dient die Architekturbeschreibung als eine gemeinsame Sprache für die Projektbeteiligten. Schon deshalb muss sie in einer für die Projektbeteiligten verständlichen Form beschrieben werden.
Ablauf einer SAAM-Bewertung
Szenarios Erheben (Schritt 1)
Die Szenarios dienen zur Beschreibung der Tätigkeiten, die das System momentan unterstützen muss oder eventuell in Zukunft unterstützen soll. Deshalb sollten sie die Aufgaben verschiedenster Projektbeteiligter (z.B. Benutzer, Auftraggeber, Marketing, Administrator, Entwickler, Wartungspersonal, etc. ) möglichst umfassend berücksichtigen. Die Szenarios werden in einem Meeting von Repräsentanten der verschiedenen Stakeholder in einem Brainstorming-ähnlichen Prozess erhoben. Wird für ein Szenario eine genauere Architekturbeschreibung benötigt, fährt man mit Schritt 2 fort und kehrt dann wieder zu Schritt 1 zurück (iterative Ausführung von Schritt 1 und 2).
Beschreibung der Architektur (Schritt 2)
Die Architekturbeschreibung sollte folgende Elemente der Architektur in einer für die Evaluationsteilnehmer verständlichen Notation enthalten:
- Komponenten und Datenelemente
- Verbindungen zwischen diesen
- Beschreibung des Systemverhaltens (umgangssprachlich oder formal)
Die Architekturbeschreibung kann die Projektbeteiligten zur Formulierung von Szenarios anregen. Auch aus diesem Grund empfiehlt sich eine iterative Ausführung der Schritte 1 und 2.
Klassifikation und Priorisierung der Szenarios (Schritt 3)
Szenarios werden in zwei Kategorien eingeteilt:
- Direkte Szenarios, d.h. Szenarios, die mit der vorhandenen Architektur ohne Änderungen ausgeführt werden können
- Indirekte Szenarios (Changecases oder Growthcases), d.h. Szenarios, zu deren Ausführung Änderungen an der Architektur vorgenommen werden müssen.
Die Priorisierung der Szenarios dient einer effizienten Architekturbewertung: nur die wichtigsten Szenarios (z.B. die wichtigsten 30% der Szenarios) werden genauer untersucht. Die Priorisierung erfolgt durch Abstimmung unter den Projektbeteiligten. SAAM schlägt hier eine offene Abstimmung vor.
Einzelne Bewertung der Szenarios (Schritt 4)
Die im vorherigen Schritt zur Bewertung ausgewählten Szenarios werden den betroffenen Elementen der Architektur zugeordnet: Für ein direktes Szenario bedeutet diese eine Beschreibung der Ausführung des Szenarios durch das System. Für ein indirektes Szenario bedeutet dies eine Beschreibung der zur Ausführung des Szenarios nötigen Änderungen an der Architektur. Dabei werden die nötigen Änderungen identifiziert und der Änderungsaufwand geschätzt.
Untersuchung von Szenariointeraktionen (Schritt 5)
Szenariointeraktion bedeutet, dass zwei oder mehr Szenarios Änderungen an derselben Komponente der Architektur erfordern. Eine hohe Szenariointeraktion kann auf zwei verschiedene Probleme hinweisen: Eine Komponente realisiert mehrere nicht zusammengehörige Funktionsbereiche. Die Architektur einer Komponente ist nicht ausreichend genau dokumentiert. In diesem Fall sollte Schritt 2 von SAAM (Architekturbeschreibung) noch einmal ausgeführt werden.
Erstellung der Gesamtbewertung (Schritt 6)
Zur Erstellung der Gesamtbewertung werden die bewerteten Szenarios gewichtet. Diese Gewichte dienen zur Relativierung der Änderungsaufwände für die einzelnen Szenarios.
Auch als "Saam´sche" Unharmonische bekannt.
Wikimedia Foundation.
