SAAM - LinkFang.de





SAAM


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

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 Szenarien 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 Szenarien durchgeführt werden müssen, wird der Änderungsaufwand oder eine damit verbundene Größe geschätzt.

Der Prozess der Zuordnung von Szenarien 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

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

Zur Bewertung von Softwarearchitekturen existieren mehrere Ansätze:

Ablauf einer SAAM-Bewertung

Beschreibung der Architektur (Schritt 1)

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 Szenarien anregen.

Szenarien erheben (Schritt 2)

Die Szenarien 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 Szenarien 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, muss zu Schritt1 zurückgekehrt werden, um eine detaillierte Architekturbeschreibung anzufertigen. Anschliessend wird anhand der detaillierten Dokumentation Schritt 2 erneut durchgeführt.

Klassifikation und Priorisierung der Szenarien (Schritt 3)

Szenarien werden in zwei Kategorien eingeteilt:

  • Direkte Szenarien, d.h. Szenarien, die mit der vorhandenen Architektur ohne Änderungen ausgeführt werden können
  • Indirekte Szenarien (Changecases oder Growthcases), d.h. Szenarien, zu deren Ausführung Änderungen an der Architektur vorgenommen werden müssen.

Die Priorisierung der Szenarien dient einer effizienten Architekturbewertung: nur die wichtigsten Szenarien (z.B. die wichtigsten 30 % der Szenarien) werden genauer untersucht. Die Priorisierung erfolgt durch Abstimmung unter den Projektbeteiligten. SAAM schlägt hier eine offene Abstimmung vor.

Einzelne Bewertung der Szenarien (Schritt 4)

Die im vorherigen Schritt zur Bewertung ausgewählten Szenarien werden den betroffenen Elementen der Architektur zugeordnet: Für ein direktes Szenario bedeutet diese eine Beschreibung der Ausführung des Szenarien durch das System. Für ein indirektes Szenario bedeutet dies eine Beschreibung der zur Ausführung des Szenarien 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 Szenarien Ä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 1 von SAAM (Architekturbeschreibung) noch einmal ausgeführt werden.

Erstellung der Gesamtbewertung (Schritt 6)

Zur Erstellung der Gesamtbewertung werden die bewerteten Szenarien gewichtet. Diese Gewichte dienen zur Relativierung der Änderungsaufwände für die einzelnen Szenarien.

Auch als "Saam´sche" Unharmonische bekannt.

Einzelnachweise

  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

Kategorien: Softwarearchitektur

Quelle: Wikipedia - http://de.wikipedia.org/wiki/SAAM (Vollständige Liste der Autoren des Textes [Versionsgeschichte])    Lizenz: CC-by-sa-3.0

Änderungen: Alle Bilder mit den meisten Bildunterschriften wurden entfernt. Ebenso alle zu nicht-existierenden Artikeln/Kategorien gehenden internen Wikipedia-Links (Bsp. Portal-Links, Redlinks, Bearbeiten-Links). Entfernung von Navigationsframes, Geo & Normdaten, Mediadateien, gesprochene Versionen, z.T. ID&Class-Namen, Style von Div-Containern, Metadaten, Vorlagen, wie lesenwerte Artikel. Ansonsten sind keine Inhaltsänderungen vorgenommen worden. Weiterhin kann es durch die maschinelle Bearbeitung des Inhalts zu Fehlern gerade in der Darstellung kommen. Darum würden wir jeden Besucher unserer Seite darum bitten uns diese Fehler über den Support mittels einer Nachricht mit Link zu melden. Vielen Dank!

Stand der Informationen: August 201& - Wichtiger Hinweis: Da die Inhalte maschinell von Wikipedia übernommen wurden, ist eine manuelle Überprüfung nicht möglich. Somit garantiert LinkFang.de nicht die Richtigkeit und Aktualität der übernommenen Inhalte. Sollten die Informationen mittlerweile fehlerhaft sein, bitten wir Sie darum uns per Support oder E-Mail zu kontaktieren. Wir werden uns dann innerhalb von spätestens 10 Tagen um Ihr Anliegen kümmern. Auch ohne Anliegen erfolgt mindestens alle drei Monate ein Update der gesamten Inhalte.