Szenarien in der Architekturevaluierung - ein Überblick

Inhaltsverzeichnis

Tabellenverzeichnis

Abbildungsverzeichnis

1 Problemstellung der Arbeit
1.1 Szenarien
1.1.1 Gründe für das CREWS-Framework
1.2 Architekturevaluierung
1.3 Szenarien in der Architekturevaluierung
1.4 Problemstellung der Arbeit

2 Grundlagen
2.1 Das CREWS-Framework
2.1.1 Unterschiedliche Sichten
2.1.2 Form view
2.1.3 Contents view
2.1.4 Purpose view
2.1.5 Lifecycle view
2.2 Methoden der szenario-basierten Architekturevaluierung
2.2.1 SAAM
2.2.2 ATAM
2.2.3 ARID
2.2.4 CBAM
2.2.5 WinCBAM
2.2.6 PASA
2.2.7 ALMA
2.2.8 FAAM

3 Betrachtung des Szenario-Begriffs in den Methoden
3.1 ATAM als Fallbeispiel
3.1.1 Szenarientypen in ATAM
3.1.2 Einschränkung der Betrachtung
3.1.3 Einordnung der unterschiedlichen Szenarientypen .
3.2 SAAM
3.3 ARID
3.4 CBAM
3.5 WinCBAM
3.6 PASA
3.7 ALMA
3.8 FAAM

4 Beziehung der szenario-basierten Architekturevaluierung zu Szenarien im RE
4.1 Szenarien innerhalb des Requirements Engineering Prozesses
4.2 Szenarien in der Architekturevaluierung und dem Requirements Engineering
4.2.1 Form der Szenarien
4.2.2 Ziele der Szenarien
4.3 Fazit

Literaturverzeichnis

Tabellenverzeichnis

3.1 Zusammenfassung der Ergebnisse der Einordnung von ATAM in das CREWS-Framework (+ = true, - = false, ? = unbestimmt)

4.1 Exemplarische Übersicht Szenarien-basierter Modellierungstechniken (aus Pohl u. Si- kora 2005)

Abbildungsverzeichnis

2.1 CREWS-Framework: Vier Sichten von Szenarien und deren Fragestellung (aus Rolland et al. (1998)) 9

3.1 Beispiel für einen typischer Utility aus Clements et al. (2001) 17

3.2 Beschreibung und Spezifikation eines Use Cases aus Rolland et al. (1998) 18

1 Problemstellung der Arbeit

Dieses erste Kapitel soll einen Überblick und eine Einführung in die Problemstellung dieser Seminar- arbeit geben. Dabei ist zu klären, was Szenarien sind (dazu werden Definitionen angegeben) und wie sich diese klassifizieren respektive charakterisieren lassen, was Architektur ist und wie diese evaluiert werden kann.

1.1 Szenarien

Szenarien werden in vielen Bereichen des Software Engineerings genutzt. Dazu zählt auch das Requirements Engineering und die Architekturevaluierung.

Im Requirements Engineering werden Szenarien wie folgt definiert :

„A scenario is a concrete description of system usage which provides a clear benefit for the actor of the system“ (nach Pohl et al. 2005)

In der Architekturevaluierung wird ein Szenario definiert als eine kurze Aussage, die die Interaktion von Stakeholdern mit dem System beschreibt (nach Clements et al. 2001).

Auf den ersten Blick sich die beiden Definitionen ähnlich. Beide Definitionen legen fest, dass es sich bei einem Szenario um eine Beschreibung der Benutzung eines Systems (also einer Interaktion) handelt.

Bei genauerem Lesen der Definitionen fallen jedoch Unterschiede auf:

- in der Architekturevaluierung wird von einer kurzen Aussage gesprochen, während im Requirements Engineering von einer konkreten Beschreibung die Rede ist
- im Requirements Engineering muss der Akteur des Szenarios einen klaren Nutzen von diesem System haben, in der Architekturevaluierung hingegen nicht.

Daraus lässt sich schlussfolgern, dass eine genauere Untersuchung der Verwendung von Szenari- en notwendig ist. Eine Grundlage für einen Vergleich zwischen der Szenarien bietet das CREWS- Framework in Rolland et al. (1998). Mit Hilfe des CREWS-Frameworks wurden auch schon mehre- re Szenarien im Requirements Engineering klassifiziert (siehe dazu Alexander 2004). Hier soll das CREWS-Framework auf die Szenarien in der Architekturevaluierung angewendet werden. Ursprüng- lich wurde das CREWS-Framework für Szenarien im Requirements Engineering entwickelt, ist jedoch aufgrund seiner Allgemeinheit auch für die Szenarien in der Architekturevaluierung anwendbar: in- nerhalb des CREWS-Frameworks werden zum Beispiel keine Attribute genannt, die sich explizit auf das Requirements Engineering beziehen.

1.1.1 Gründe für das CREWS-Framework

Das CREWS-Framework (Rolland et al. 1998) ist entwickelt worden, um eine Klassifizierung von Szenarien im Requirements Engineering zu ermöglichen. Es gab drei Gründe es zu entwickeln:

1. Es soll helfen zu klären und zu verstehen, warum es szenario-basierte Ansätze gibt
2. Es soll den industriellen Gebrauch von Szenarien darstellen
3. Es soll Wissenschaftlern helfen, mehr innovative szenarien-basierte Ansätze zu entwickeln Zwei der drei Gründe treffen in dieser Arbeit zu:

- Die hier untersuchten Methoden sind gebräuchlich in der Industrie. So wird insbesondere die genauer untersuchte Methode industriell genutzt (siehe Kazman et al. 1999; Clements et al. 2001). Dies führt auch unmittelbar zum zweiten Grund:
- Wissenschaftler entwickeln auf Basis der bisherigen Erfahrungen die vorhandenen Ansätze weiter, was bei den untersuchten Methoden aufgefallen ist.

1.2 Architekturevaluierung

Software Architekturen sind an sich erst seit 1990 im Software Engineering richtig anerkannt. Sie wurde aber schon früher von David Parnas, Fred Brooks und Edsgar Dijkstra in den sechziger und achtziger Jahren geprägt.

Aber was ist Software Architektur? Software Architektur ist der erste Schlüssel zum verstehen eines (Software-) Systems, eine Basis mit dem Stakeholder untereinander kommunizieren können die normalerweise keine gemeinsame Sprache haben. So ist Software Architektur die Manifestation der ersten Designentscheidungen und der Grundstein für die Projektorganisation.

Software Architektur ist meist eine wiederverwendbare und übertragbare Abstraktion eines Systems, was dann zukünftige Systeme mit einer ähnlichen Architektur zu verstehen hilft (nach Clements et al. 2001).

Um diese Architektur auf ihre Korrektheit zu überprüfen, gibt es die Architekturevaluierung. Dabei wird überprüft, ob es Fehler, Unstimmigkeiten zwischen Stakeholdern oder Zielkonflikte gibt. Ebenso wird die Architektur auf wichtige Qualitätsaspekte hin untersucht.

Software Architekturen sollten auf jeden Fall evaluiert werden. Da diese schon in einem relativ frühen Stadium des kompletten Entwicklungsprozesses zur Verfügung steht, ist es auch möglich, schon früh Fehler zu finden und zu korrigieren, die im späteren Prozess nur sehr schwer korrigiert werden können. Dies kann schnell zu Problemen mit dem Kunden führen. Zudem ist die Architekturevaluierung eine kostengünstige Möglichkeit das System zu testen, da es bisher erst auf dem Papier existiert und noch keine extremen Entwicklungskosten hat entstehen lassen.

Das Ergebnis der Architekturevaluierung ist ein Bericht, in dem zwei Fragen beantwortet werden sollten:

1. Ist die Software Architektur, für das System wofür sie entwickelt wurde, angemessen?
2. Welche der eventuell konkurrierenden, unterschiedlichen Architekturen ist besser für das System?

Um eine Software Architektur zu evaluieren, gibt es unterschiedliche Möglichkeiten: zum einen gibt es Modelle die genutzt werden können oder man kann sie durch (szenario-basierte) Methoden evaluieren. Da Modelle zur Evaluierung noch validiert werden (Babar u. Gorton 2004), werden in dieser Arbeit Methoden genutzt, die auf Szenarien beruhen. Ein Vorteil der szenario-basierten Methoden ist die einfache Verständlichkeit durch die Szenarien. Alle beteiligten Stakeholder können meist alle Szenarien verstehen und diese auch selber entwickeln (Clements et al. 2001). Modelle hingegegen sind abstrakter und erfordern eine Einarbeitung.

1.3 Szenarien in der Architekturevaluierung

Somit nimmt diese Arbeit Bezug auf die Definition von Szenarien in der Architekturevaluierung aus Clements et al. (2001) (siehe auch Abschnitt 1.1 auf der vorherigen Seite). Durch die Definition von Szenarien kann man Beispiele für Szenarien ableiten: so würde ein Wartungsspezialist beispiels- weise Änderungen an einem System beschreiben, zum Beispiel das Update des Betriebssystems, ein Entwickler würde beschreiben, wie aus einer Software Architektur eine Software erstellt wird oder er würde die Performanz der Software vorhersagen, während ein Produktlinienmanager beschreiben würde, wie die Software Architektur für die nächste Generation einer Produktlinie wiederverwendet würde. Durch diese unterschiedlichen Sicht- und Nutzungsweisen entstehen unterschiedliche Typen von Szenarien:

Use Case-Szenarien sind zum Beispiel aus Anwendersicht geschriebene Szenarien Growth- und Exploratory-Szenarien zum Beispiel aus Sicht von Entwicklern oder Wartungsspezia- listen Durch diese unterschiedlichen Szenarientypen sind alle Stakeholder mit ihren unterschiedlichen Sicht- weisen bei den Szenarien, und damit auch an deren Erstellung, vertreten beziehungsweise beteiligt.

1.4 Problemstellung der Arbeit

Ziel der Arbeit ist die Beziehung zwischen dem Requirements Engineering und der Architekturevalu- ierung zu untersuchen. Dabei soll die Arbeit dazu beitragen, einen durchgehenden Softwareentwick- lungsprozess auf Basis von Szenarien zu entwickeln. Um eine geeignete Methode für die Architekture- valuierung zu finden, die sich mit dem Requirements Engineering und deren Szenarien gut verwenden lässt, müssen die Methoden vergleichbar sein. Um dies zu erreichen, wird eine Szenarienklassifizierung des Requirements Engineering auf die Architekturevaluierung angewendet. Dazu werden unterschied- liche szenario-basierte Methoden der Architekturevaluierung (beziehungsweise deren Verwendung von Szenarien) untersucht beziehungsweise m.H.d. CREWS-Frameworks (Rolland et al. 1998) charak- terisiert. Detailliert wird dazu auf die Methode ATAM¹ eingegangen, da diese gut dokumentiert ist und oft angewendet wurde (zum Beispiel in Kazman et al. 1999). Zusätzlich wird ein Überblick über die weiteren Methoden gegeben und die wesentlichen Unterschiede zu ATAM, im Bezug auf die Verwendung von Szenarien, erläutert.

Innerhalb dieses Themenkomplexes werden folgende Fragen aufgeworfen:

1. Warum werden Szenarien in der Architekturevaluierung genutzt?
2. Wie werden Szenarien in der Architekturevaluierung genutzt?
3. Welche Arten von Szenarien werden in der Architekturevaluierung genutzt?
4. Welche Beziehung haben Szenarien aus der Architekturevaluierung zu Szenarien im Require- ments Engineering ? dazu insbesonders:

a) Haben die Szenarien die gleichen Ziele, wenn ja, welche?
b) Welche Szenarien eigenen sich für beide Felder?
c) Sind Szenarien aus dem Requirements Engineering in der Architekturevaluierung wieder- verwendbar?

2 Grundlagen

Dieses Kapitel soll die Grundlagen vermitteln, die für diese Arbeit nötig sind. Dazu wird das CREWSFramework erläutert und eine Übersicht über die untersuchten szenario-basierten Methoden in der Architekturevaluierung gegeben.

2.1 Das CREWS-Framework

Dieser Abschnitt der Arbeit wird eine kurze Einführung in das CREWS-Framework geben. Dabei wird Bezug genommen auf die Definition des CREWS-Frameworks in Rolland et al. (1998).

2.1.1 Unterschiedliche Sichten

Das CREWS-Framework betrachtet Szenarien aus vier unterschiedlichen Sichten, die in Abbildung 2.1 auf der nächsten Seite dargestellt sind und unten weiter erläutert werden.

Dabei werden die einzelnen Sichten in Facetten unterteilt, die wiederum aus einzelnen Attributen bestehen. Den Attributen können dem untersuchten Szenario entsprechende Ausprägungen zugeordnet werden, die dann das Szenario klassifizieren beziehungsweise charakterisieren.

2.1.2 Form view

In dieser Sicht wird die Darstellungsform des Szenarios beschrieben.

Die Form view enthält zwei Facetten: die description und die presentation Facette.

2.1.2.1 Description Facette

Die description Facette besteht aus zwei Attributen: medium Beschreibt, auf welchem Medium das Szenario beschrieben wurde, mögliche Ausprägungen sind {text, graphics, image, video, software prototype}, mehrere Ausprägungen sind möglich notation Beschreibt, mit welchen Formalismen das Szenario beschrieben wurde, beispielsweise eine einfache Ausdrucksweise oder eine Verwendung von Fachtermini, mögliche Ausprägungen sind {formal, semi-formal, informal}

2.1.2.2 Presentation Facette

Durch die presentation Facette soll die Darstellungsform des Szenarios charakterisiert werden. Dazu werden zwei Attribute genutzt: interactivity Hat der Betrachter des Szenarios die Möglichkeit zu beeinflussen, wie sich das Szenario über die Zeit fortsetzt? Gibt es zum Beispiel per Hypertext die Möglichkeit, zu verbundenen Dokumenten zu kommen oder gibt es Abstraktions-, Verfeinerungs- oder Explorationslinks? Mögliche Ausprägungen sind {none, hypertext-like, advanced} animation Gibt an, ob es Animationen in der Darstellung des Szenario gibt (true oder false)

Abbildung 2.1: CREWS-Framework: Vier Sichten von Szenarien und deren Fragestellung (aus Rolland et al. (1998))

Abbildung in dieser Leseprobe nicht enthalten

2.1.3 Contents view

Durch die Contents view soll die Art des Inhalts charakterisiert beziehungsweise klassifiziert werden. Hier wird auch beschrieben, wie abstrakt oder genau ein Szenario ist.

2.1.3.1 Abstraction Facette

Die abstraction Facette gibt die Abstraktionsebene an, ob ein Szenario instantiiert ist, also zum Beispiel von einem abstrakten Szenario abgeleitet ist oder ein abstraktes Szenario selber ist. Ebenso sind auch Mischformen möglich. Dazu benutzt das CREWS-Framework drei Attribute:

instance Beschreibt, ob das Szenario eine konkrete Handlung oder ein repräsentatives Handeln für eine abstrakte Handlung ist (true oder false) type Ist das Gegenteil von instance, es handelt sich um ein abstraktes Szenario (true oder false) mixed Eine Mischform aus instance und type (true oder false)

Ein Beispiel für die description Facette könnte so aussehen:

John Doe will am Geldautomaten Geld ziehen. Nachdem er zur Identifikation seine PIN eingegeben hat fällt der Strom aus.

Dies wäre ein Beispiel für mixed(true). Es wird hier konkret von einer Person (wohl einem Anwender, also einer Instanz von „Person“) gesprochen, wobei der Strom ausfällt.

John Doe will am Geldautomaten Geld ziehen. Nachdem er zur Identifikation seine PIN eingegeben hat liegt an der 5V Leitung keine Spannung mehr an.

Im Vergleich zum obigen Beispiel ist dies hier eine reine Instanz. Es wird konkret gesagt, wo der Strom ausfällt, somit wäre es hier keine Mischform mehr mixed(false), sondern instance(true).

2.1.3.2 Context Facette

Diese Facette bezieht sich auf den Kontext, dem das Szenario zugeordnet ist. Es besteht aus vier Attributen: system internal Gibt an, ob interne Prozesse des Systems beschrieben werden (true oder false) system interaction Gibt es eine Interaktion mit dem System von außen (zum Beispiel durch Menschen oder andere Systeme, true oder false) organisational context Gibt an, ob das Szenario mit dem Unternehmen in Verbindung steht, zum Beispiel Daten über dieses wissen muss respektive Regeln von B2B Prozessen oder ähnliches (true oder false) organisational environment Spielt die Umwelt des Unternehmens eine Rolle in dem Szenario (zum Beispiel durch EU Richtlinien, true oder false)

2.1.3.3 Argumentation Facette

Ein Szenario kann Entscheidungen, Positionen und Argumente enthalten. Um dieses zu charakterisieren, adaptiert das CREWS-Framework das IBIS Modell¹ (unter anderem in Conklin u. Begeman (1988) aus Rolland et al. (1998)) und unterscheidet zwischen den folgenden vier Attribute: positions Zeigt das Szenario alternative Lösungen für ein Problem auf? (true oder false) arguments Werden Argumente pro oder contra für eine Position genannt? (true oder false) issues Werden Probleme oder Konflikte durch unterschiedliche Positionen im Szenario angesprochen? (true oder false) decisions Gibt an, ob Entscheidungen innerhalb des Szenarios getroffen werden (true oder false)

2.1.3.4 Coverage Facette

Die Coverage Facette versucht zu klassifizieren, welche Informationen durch das Szenario bezogen werden sollen. Sie besteht aus drei Attributen:

functional Beschreibt, welche funktionalen Aspekte beschrieben sind. Ausprägungen sind {structure, function, behaviour } intentional Sind in dem Szenario die Ziele des Unternehmens berücksichtigt beziehungsweise enthalten und wenn ja, wie? Ausprägungen sind {goal, problem, responsibility, opportunity, cause, goal dependency} non-functional Gibt es nicht-funktionale Attribute die in dem Szenario enthalten sind? Wenn ja, wel- che sind es? Mögliche Ausprägungen sind (mehrere möglich ): {performance, time constraints, cost constraints, user support, documentation, examples, backup/recovery, maintainability, fle- xibility, portability, security/safety, design constraints, error handling}

2.1.4 Purpose view

Mit Hilfe der Purpose view wird untersucht, was für eine grundsätzliche Absicht das Szenario verfolgt. Es ist nicht in weitere Facetten unterteilt, sondern hat direkt drei Attribute:

descriptive Wird mit Hilfe des Szenarios ein Prozess durchlaufen, um darin die Operationen zu ver- stehen? Werden die Personen und das Triggering innerhalb des Szenarios betrachtet und das System als Black-Box betrachtet? (true oder false) exploratory Werden unterschiedliche Lösungen und deren Argumentation erkundet? (true oder false) explanatory Gibt es Erklärungen und Gründe für eine Situation oder ein bestimmtes Verhalten? (true oder false)

2.1.5 Lifecycle view

Im CREWS-Framework wird zum einen die dynamische und zum Anderen die statische Perspektive betrachtet. Die Lifecycle view betrachtet den Lebenszyklus des Szenarios, also die dynamische Perspektive. Dazu benutzt es zwei Facetten.

2.1.5.1 Lifespan Facette

Die Lifespan Facette besitzt ein Attribut, welches die Lebensspanne des Szenarios wiedergibt:

lifespan Wie lange überlebt das Szenario? Ist es kurzlebig oder existiert das Szenario so lange wie die Dokumentation des Projektes existiert. Mögliche Ausprägungen sind {transient, persistent}

2.1.5.2 Operation Facette

Diese Facette beschreibt, wie mit dem Szenario innerhalb der Requirements Engineering Prozesses umgegangen wird. Die Facette hat fünf Attribute:

capture Beantwortet die Frage danach, wie das Szenario enstanden ist {from_scratch oder by_reuse} refinement Wurde das Szenario verfeinert, so dass der Inhalt aber gleich bleibt? (true oder false) integration Wurden mehrere Szenarien zu einer „Familie“ zusammengestellt? (true oder false) expansion Wurde das Szenario so erweitert, das für eine ursprüngliche Problemstellung nun IT- Lösungen genutzt werden oder zeigt das Szenario zum Beispiel einen zukünftigen Arbeitsplatz? (true oder false) deletion Wird das Leben des Szenarios beendet? Es gibt nur zwei Möglichkeiten, wo dies geschehen kann:

1. Wenn das Szenario unterstützend genutzt wird, um Anforderungen zu ermitteln, kann es direkt danach wieder verworfen werden
2. Wenn das Szenario Teil einer Anforderungsspezifikation ist, ist seine Lebensdauer gleich der einer der Anforderungsspezifikationen

Die Ausprägung ist entweder true oder false.

2.2 Methoden der szenario-basierten Architekturevaluierung

Innerhalb dieses Abschnitts werden nun einige szenario-basierte Methoden kurz vorgestellt.

Diese Methoden dienen dazu, die Software Architektur des betrachteten Systems zu überprüfen. Das Ergebnis einer Methode ist meistens ein Dokument, in dem Fehler in der Architektur erfasst werden. Ebenso helfen einige Methoden auch dabei, die geeignetste Software Architektur aus konkurrierenden Architekturen zu finden.

Die meisten Methoden haben einen festgelegten Ablauf, wie diese durchzuführen sind.

2.2.1 SAAM, Software Architecture Analysis Method

SAAM ist eine der einfachsten Methoden zur szenario-basierten Evaluierung von Software Architek- turen. Es gibt unterschiedliche Entwicklungsstufen. Erstmals wurde SAAM bei Kazman et al. (1994) vorgestellt. Es wurde im Laufe der Zeit immer weiter verfeinert und ist nun in Clements et al. (2001) in der aktuellsten Version. Die Methode besteht aus sechs Schritten (nach Clements et al. 2001):

[...]

---

¹ Architecture Trade-off analysis Method, nach Clements et al. (2001)

¹ Issue Based Information Systems