Szenariobasierte Architekturbewertung
Die szenariobasierte Architekturbewertung stellt einen Ansatz zur Bewertung von Softwarearchitekturen dar.
Betrachtungsebene
[Bearbeiten | Quelltext bearbeiten]Szenariobasierte Architekturbewertungsverfahren nähern sich der Aufgabe, eine Softwarearchitektur zu bewerten, meist auf einer gröberen Ebene als Architekturmetriken. Im Gegensatz zu Softwarearchitekturmetriken, die eine Softwarearchitektur auf feingranularer Ebene untersuchen, arbeiten szenariobasierte Ansätze zur Architekturbewertung eher auf einer mittleren Detailebene.
Vorgehen
[Bearbeiten | Quelltext bearbeiten]Szenariobasierte Architekturbewertungsverfahren verstehen sich häufig als ein Vorgehensmodell, welches zu einer Architekturbewertung führt. Die szenariobasierten Verfahren liefern mehr als nur eine Rechenmethodik oder Messanweisungen, sie beschreiben mehr oder weniger detailliert Schritte, über die man zu einer Architekturbewertung gelangt. Die wichtigsten Schritte in einer szenariobasierten Architekturbewertung finden sich in vielen der unterschiedlichen Verfahren wieder:
- Erheben und Priorisieren von Szenarios
- Erstellen und Beschreiben der Architektur (bzw. der zu vergleichenden Architekturen, falls dies das Ziel der Bewertung darstellt)
- Bewertung der Softwarearchitektur aus dem Blickwinkel der wichtigsten erhobenen Szenarios
- Präsentieren der Ergebnisse, erstellen eines Berichts
Einsatz von Szenarios
[Bearbeiten | Quelltext bearbeiten]Neben diesen Schritten sind den Vorgehensmodellen zur szenariobasierten Architekturbewertung aber auch noch einige Techniken und Konzepte gemeinsam. Das wichtigste Konzept stellt dabei das Szenario dar.
In diesem Kontext versteht man unter einem Szenario eine kurze Beschreibung einer einzigen Interaktion eines Betroffenen oder einer Interessengruppe (z. B. Kunden, Pflegepersonal etc.) mit einer Anwendung.
Eine grundlegende Klassifikation, die zum Beispiel im Verfahren SAAM zum Einsatz kommt, unterteilt die Szenarios in:
- direkte Szenarios (Szenarios, die das System mit der aktuellen Architektur ohne Änderungen durchführen kann.)
- indirekte Szenarios (Szenarios, die das System nur nach Änderungen an der Architektur durchführen kann. Zu dieser Kategorie gehören auch die Szenarios, die zur Operationalisierung einer ungewissen Zukunft dienen.)
Operationalisierung von Qualitätsmerkmalen durch Szenarios
[Bearbeiten | Quelltext bearbeiten]Szenariobasierte Architekturbewertungsverfahren setzen Szenarios ein um genau zu spezifizieren, was die Projektbeteiligten unter Qualitätsmerkmalen wie z. B. "Änderbarkeit" verstehen. Dieses Vorgehen ermöglicht es, Qualitätsattribute, die in Anforderungsdokumenten oft nur vage und unterschiedlich interpretierbar spezifiziert sind, zu operationalisieren. Demnach lassen sich Szenarios den verschiedenen Qualitätsmerkmalen, die sie spezifizieren zuordnen. Die Szenarios lassen sich auch als Testfälle für die Architekturbewertung verstehen. Ebenso, wie die Qualität eines Softwaretests vom Testplan abhängt, hängt die Qualität des mit einem derartigen Verfahren erzielten Bewertungsergebnisses entscheidend von der Qualität der erhobenen Szenarios ab. Die Szenarios müssen die aktuellen und zukünftigen Anforderungen an die Anwendung möglichst umfassend abbilden. Kein wichtiges und wahrscheinliches Szenario darf also fehlen. Deshalb ist die Auswahl der Personen, die an der Bewertung teilnehmen wichtig. Die Ansichten wichtiger Projektbeteiligter müssen dabei entsprechend vertreten sein.
Bewertung der Szenarios
[Bearbeiten | Quelltext bearbeiten]Die Techniken, die zur Bewertung der einzelnen Szenarios zum Einsatz kommen, hängen von der Art des Szenarios und dem Ziel der Bewertung ab. Oft ist bei direkten Szenarios der Betrachtungsgegenstand, wie die Architektur ein Szenario ausführt. Bei indirekten Szenarios steht eher im Mittelpunkt der Betrachtungen, welche Änderungen zur Ausführung der Szenarios an der Architektur durchgeführt werden müssen. Die Frage, inwieweit eine zu bewertende Softwarearchitektur bestimmte Qualitätsanforderungen erfüllt oder bezüglich dieser Qualitätsanforderungen Risiken mit sich bringt, kann ein szenariobasiertes Verfahren durch eine qualitative (z. B. Beschreibung von Risikopunkten in der Architektur) oder quantitative (z. B. Schätzung des Aufwands für zukünftige Änderungen in Personentagen) Untersuchung beantworten.
Zusatznutzen aus der Bewertung
[Bearbeiten | Quelltext bearbeiten]Neben den oben erwähnten Szenariobewertungen produziert eine szenariobasierte Architekturbewertung auch eine, über die Szenarios genauere spezifizierte Beschreibung qualitativer Anforderungen an das betrachtete System. Auch die Architekturbeschreibung kann im Rahmen eines derartigen Bewertungsverfahrens weiter verbessert werden. Weiterer Nutzen einer szenariobasierten Architekturbewertung liegt:
- in den Meetings, die Bestandteil vieler szenariobasierter Verfahren sind; diese fördern die Kommunikation zwischen den Projektbeteiligten;
- in einem verbesserten Verständnis der Softwarearchitektur;
- in einer Möglichkeit, den Prozess der Architekturentstehung zu verbessern
Verfahren
[Bearbeiten | Quelltext bearbeiten]Mehrere Verfahren nutzen diesen Ansatz:
- SAAM Software architecture analysis method
- ATAM Architecture tradeoff analysis method:[1]
- ACDM Architecture-centric design method[2]
Siehe auch
[Bearbeiten | Quelltext bearbeiten]- IEEE 1471 zur Architekturbeschreibung von Softwaresystemen
Literatur
[Bearbeiten | Quelltext bearbeiten]- Rick Kazman 1996: Scenario-Based Analysis of Software Architecture
- Rick Kazman: Toward a Discipline of Scenario-based Architectural Engineering
- Paulo Merson 2009: Data Model as an Architectural View
Weblinks
[Bearbeiten | Quelltext bearbeiten]- Architecture Tradeoff Analysis Method (ATAM) kurz erklärt Ablauf der Methode mit Phasen, Schritten, Beispielszenarien, einem Utility Tree und typischer Ergebnisstruktur
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ Architecture Tradeoff Analysis Method. Carnegie Mellon Software Engineering Institute, abgerufen am 14. Januar 2013.
- ↑ Lattanze, Anthony J. (2009). Architecting Software Intensive Systems: A Practitioners Guide. Software Engineering. CRC Press. ISBN 978-1-4200-4569-7.