i

Inhaltsverzeichnis

Tabellenverzeichnis iii   

Abbildungsverzeichnis   iv

1  Problemstellung der Arbeit  5

1.1  Szenarien  5

1.1.1  Gründe für das CREWS-Framework  5

1.2  Architekturevaluierung  6

1.3  Szenarien in der Architekturevaluierung  6

1.4  Problemstellung der Arbeit  7

2  Grundlagen  8

2.1  Das CREWS-Framework  8

2.1.1  Unterschiedliche Sichten  8

2.1.2  Form view  8

2.1.3  Contents view  9

2.1.4  Purpose view  10

2.1.5  Lifecycle view  11

2.2  Methoden der szenario-basierten Architekturevaluierung  11

2.2.1  SAAM  11

2.2.2  ATAM  12

2.2.3  ARID  13

2.2.4  CBAM  13

2.2.5  WinCBAM  14

2.2.6  PASA  14

2.2.7  ALMA  14

2.2.8  FAAM  15

3  Betrachtung des Szenario-Begriffs in den Methoden  16

3.1  ATAM als Fallbeispiel  16

3.1.1  Szenarientypen in ATAM  16

3.1.2  Einschränkung der Betrachtung  17

3.1.3  Einordnung der unterschiedlichen Szenarientypen  18

3.2  SAAM  23

3.3  ARID  23

3.4  CBAM  23

3.5  WinCBAM  25

3.6  PASA  25

3.7  ALMA  25

3.8  FAAM  25

ii

4  Beziehung der szenario-basierten Architekturevaluierung zu Szenarien im RE  26

4.1  Szenarien innerhalb des Requirements Engineering Prozesses  26

4.2  Szenarien in der Architekturevaluierung und dem Requirements Engineering  26

4.2.1  Form der Szenarien  27

4.2.2  Ziele der Szenarien  27

4.3  Fazit  28

Literaturverzeichnis   32

iii

Tabellenverzeichnis

3.1 Zusammenfassung der Ergebnisse der Einordnung von ATAM in das CREWS-Framework (+ = true, - = false, ? = unbestimmt) . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1 Exemplarische Übersicht Szenarien-basierter Modellierungstechniken (aus Pohl u. Si- kora 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

iv

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 Seminararbeit 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 Szenarien 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 mehrere Szenarien im Requirements Engineering klassifiziert (siehe dazu Alexander 2004). Hier soll das CREWS-Framework auf die Szenarien in der Architekturevaluierung angewendet werden. Ursprünglich 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: innerhalb 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

1 Problemstellung der Arbeit 6

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

1 Problemstellung der Arbeit 7

von Szenarien kann man Beispiele für Szenarien ableiten: so würde ein Wartungsspezialist beispielsweise Ä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 Wartungsspezialisten

Durch diese unterschiedlichen Szenarientypen sind alle Stakeholder mit ihren unterschiedlichen Sichtweisen 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 Architekturevaluierung zu untersuchen. Dabei soll die Arbeit dazu beitragen, einen durchgehenden Softwareentwicklungsprozess auf Basis von Szenarien zu entwickeln. Um eine geeignete Methode für die Architekturevaluierung 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 unterschiedliche szenario-basierte Methoden der Architekturevaluierung (beziehungsweise deren Verwendung von Szenarien) untersucht beziehungsweise m.H.d. CREWS-Frameworks (Rolland et al. 1998) charakterisiert. 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 Requirements 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 wiederverwendbar?

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

2 Grundlagen

Dieses Kapitel soll die Grundlagen vermitteln, die für diese Arbeit nötig sind. Dazu wird das CREWS-Framework 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)