SAAM

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Dieser Artikel handelt von einer Methode zur Analyse von Software Architektur; für "Surface-to-Air Anti-missile" im militärischen Gebrauch siehe Surface to Air Missile.

SAAM ist ein Akronym für (englisch )„software architecture analysis method“. Das Verfahren wurde von Rick Kazman, Gregory Abowd, Len Bass und Paul Clements entwickelt.[1]

Kurzbeschreibung SAAM[Bearbeiten]

SAAM ist das erste publizierte und eines der einfacheren Verfahren zur szenariobasierten Architekturbewertung. SAAM eignet sich zur Untersuchung von Softwarearchitekturen im Hinblick auf qualitative Anforderungen wie Verfügbarkeit(Availability), Modifizierbarkeit(Modifyability), Performance, Sicherheit(Security), Testbarkeit(Testability) und Benutzbarkeit(Usability) aber auch zur Evaluation des Funktionsumfangs (funktionale Anforderungen einer Software(architektur)). Grundsätzlich werden bei einer SAAM-Bewertung Szenarien 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.

Ziel der SAAM[Bearbeiten]

Ziel der Softwarearchitekturbewertung ist es, eine Softwarearchitektur auf ein bestimmtes Qualitätsmerkmal (oder mehrere Qualitätsmerkmale gleichzeitig) hin zu untersuchen. Mögliche Untersuchungsziele sind dabei:

  • Vergleich von zwei alternativen Softwarearchitekturen bezüglich des Qualitätsmerkmals / der Qualitätsmerkmale
  • Untersuchung inwieweit eine Softwarearchitektur bestimmte Qualitätsmerkmale erfüllt
  • Untersuchung von Risiken, die eine Softwarearchitektur bezüglich bestimmter Qualitätsmerkmale mit sich bringt
  • Untersuchung inwieweit die vorgegebene Softwarearchitektur im Code auch eingehalten wurde

Verfahren zur SAAM[Bearbeiten]

Zur Bewertung von Softwarearchitekturen existieren mehrere Ansätze:

Ablauf einer SAAM-Bewertung[Bearbeiten]

Szenarios erheben (Schritt 1)[Bearbeiten]

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)[Bearbeiten]

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)[Bearbeiten]

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)[Bearbeiten]

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)[Bearbeiten]

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)[Bearbeiten]

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.

Einzelnachweise[Bearbeiten]

  1. http://www.sei.cmu.edu/library/abstracts/whitepapers/scenariobasedanalysisnov1996.cfm%7Ctitle= http://www.sei.cmu.edu/library/abstracts/whitepapers/scenariobasedanalysisnov1996.cfm |author= Rick Kazman, Gregory Abowd, Len Bass, Paul Clements|accessdate=2006-10-22