Softwarearch itektu r- An alysem eth od en

Transkript

1 Softwarearch itektu r- An alysem eth od en Ein Überblick Matt hias Füssel Ingo Rauschenberg Seminar: Soft ware- Architekt ur Humboldt Universität zu Berlin

2 Überblick Einführende Bem erkungen Die einzelnen Methoden Zusamm enfassung

3 Begriffe Qualitätsattribut (eine) Software- Qualität Software- Architektur View Architektur- Bewertungstechniken Qualitatives Fragen Quantitatives Messen

4 Betrach tete Meth od en SAAM SAAMCS ESAAMI SAAMER ATAM SBAR ALPSM SAEM CBAM ALMA FAAM

5 Betrach tete Asp ekte d er Meth od en Ziele Techniken Betrachtete Qualitätsattribute Beteiligte Interessenvertreter Vorgehen Benötigte Softwarearchitektur- Beschreibung Bemerkungen

6 Scen ario- Based Arch itectu re An alysis Meth od SAAM

7 SAAM: Ziele Vereinbarkeit grundlegender Architekturannahmen mit den geforderten Eigenschaften einer Anwendung überprüfen Architekturrisiken abschätzen Verschiedene Architekturansätze vergleichen

8 SAAM: Tech n iken Szenarien beleuchten die Eigenschaften der Softwarearchitektur Szenarien für alle Aktivitäten und Änderungen, die das System unterstützen soll Direkte Szenarien: ohne Architekturänderungen Indirekte Szenarien Bewertet, welche Szenarien welche Änderungen nötig machen

9 SAAM: Qu alitätsattribu te Jedes Qualitätsattribut, dass sich in Szenarien auswirkt, m öglich Meistens Veränderbarkeit betrachtet Auch Portabilität, Erweiterbarkeit, funktionale Vollständigkeit

10 SAAM: In teressen svertreter Harmonisiert viele Wünsche vieler Interessensvertreter Schafft gemeinsame Verständnisbasis für spätere Entscheidungen Externe Interessensvertreter, interne Interessensvertreter, SAAM- Team

11 SAAM: Vorgeh en Szenarienentwicklung Softwarearchitektur- Beschreibung Bewertung der Szenarien Szenarienwechselwirkungen

12 SAAM: Vorgeh en

13 SAAM: SA- Besch reibu n g Softwarearchitektur muss grundsätzlich stehen Funktionalität, Struktur und deren Zuordnung Statische und dynamische Beschreibung Einfaches, kleines Lexikon zum Grundverständnis

14 SAAM: Bem erku n gen lange angewendet Mehrere Fallstudien Liefert keine genaue Qualitätsmaßzahl...aber eine Grundlage, die Vergleiche mehrerer Architekturen erlaubt

15 SAAM Fou n d ed on Com p lex Scen arios SAAMCS

16 SAAMCS: Ziele Basiert auf SAAM Betrachtet Komplex ität von Szenarien Risikoabschätzung einziges Ziel

17 SAAMCS: Tech n iken Sucht Szenarien, deren Realisierung möglicherweise komplex ist Betrachtet die Initiatoren von Szenarien, die SA- Beschreibung und Versionskonflikte Liefert Klassen von Szenarien, die schwierig zu im plem entieren sind

18 SAAMCS: Qu alitätsattribu te Analysiert Flexibilität

19 SAAMCS: In teressen svertreter Berücksichtigt die Einbeziehung der Interessensvertreter Besondere Bedeutung für Initiator eines Szenarios

20 SAAMCS: Vorgeh en

21 SAAMCS: Vorgeh en Diagramm erstellen: Kategorien komplexer Szenarien: Anpassung an das System mit externen Effekten, an die Umgebung mit Effekten auf das System, an die Mikroarchitektur, an die Makroarchitektur, Versionskonflikte Änderungsquellen: Funktionale Anforderungen, Qualitätsanforderungen, ex terne Kom ponenten, technische Um gebung

22 SAAMCS: Vorgeh en Instrument zur Bewertung der Auswirkungen eines Szenarios 4 Stufen der Auswirkung: keine Auswirkung, eine Komponente, mehrere Komponenten, die Architektur Anzahl der Eigentümer, die am Inform ationsprozess beteiligt sind 4 Stufen bezüglich Versionskonflikten

23 SAAMCS: SA- Besch reibu n g Software- Architektur muss fertig sein SAAMCS unterscheidet Mikroarchitektur und Makroarchitektur

24 SAAMCS: Bem erku n gen Wurde für Geschäftsinformationssysteme erfolgreich verwendet

25 Exten d in g SAAM by In tegration in th e Dom ain ESAAMI

26 ESAAMI: Ziele Konzentriert sich auf die Dom äne Berücksichtigt Wiederverwendbarkeit ex istierenden Wissens

27 ESAAMI: Tech n iken, In teressen s- vertreter, Qu alitätsattribu te Wie SAAM

28 ESAAMI: Vorgeh en Wiederverwendbare Softwarearchitekturen erhalten Analyse- Vorlage Dam it geeignetste SA auswählen Ausgewählte SA wird Ausgangspunkt für das Architekturdesign

29 ESAAMI: Vorgeh en

30 ESAAMI: SA- Besch reibu n g Faktoren für Wiederverwendbarkeit: Gemeinsame Basis für mehrere Systeme einer Dom äne Ausreichend flex ible Architekturen Dokumentation der Eigenschaften der Architekturen

31 ESAAMI: Bem erku n gen Methode wird noch weiterentwickelt

32 Software Arch itectu re An alysis Meth od for Evolu tion an d Reu sability SAAMER

33 SAAMER: Ziele Erweitert SAAM für Qualitätsattribute Evolution und Wiederverwertbarkeit

34 SAAMER: Tech n iken Szenarien beschreiben Funktionalität des System s erkennen, wo möglicherweise Änderungen nötig werden werden Szenarien basieren auf Architekturzielen und Wünschen der Interessensvertreter Szenarien und der structural view identifizieren Komponenten, die geändert werden müssen oder für Wartungsarbeiten nützlich sind

35 SAAMER: Qu alitätsattribu te Evolution Integriert Wartbarkeit, Veränderbarkeit Wiederverwertbarkeit

36 SAAMER: In teressen svertreter Wie SAAM Benötigte Änderungen Erfahrungen der Domänenex perten

37 SAAMER: Vorgeh en Informationen sammeln über Interessensvertreter, SA, Qualität, Szenarien Benutzbare Artefakte m odellieren Analyse Bewertung

38 SAAMER: Vorgeh en Wann ausreichend Szenarien entwickelt? Streng an Ziele gebunden: Interessensvertreter, Architektur und Qualität Quality Function Deployment: Überdeckung der Qualitätsattribute berechnet, mit deren Priorität bewertet Wichtiges Kriterium: Szenarienwechselwirkungen Aber m öglicherweise nicht zu verm eiden

39 SAAMER: SA- Besch reibu n g Statisch: Klassifizierung und Generalisierung der Komponenten, Abschätzung des Änderungsaufwands Dynamisch: Verhaltensaspekte, Kontrollund Komm unikationsfluss Mapping: Zuordnung zwischen Kom ponenten und Funktionen

40 SAAMER: Bem erku n gen Bei einem Telekommunikationssystem angewendet