Kapitel 1 Applikations-Architektur V

Transkript

1 Kapitel 1 Applikations-Architektur V Software Engineering FS 2015 Prof. Dr. Jana Köhler jana.koehler@hslu.ch

2 Gesamtüberblick I. Software Architektur Grundbegriffe II. Prinzipien & Taktiken III. Stile und Muster IV. Sichten, Architekturentscheidungen und Dokumentation V. Bewertung von Architekturen (ATAM) VI. Beruf des IT Architekten VII. Fallstudie Fillialbestellstystem aus Modul Applikationsentwicklung 2

3 "There is no such thing as an inherently good or bad architecture. Architectures are either more or less fit for some purpose." Bass, Clements, Katzman 3

4 Wie komme ich zu einer guten Architektur Den Prozess des Entwurfs, des Prototyping, der Umsetzung gut beherrschen Die Strukturen gut entwerfen Empfehlungen sind möglich, aber keine Rezepte "rules of thumb" Erfahrungen aus guten Projekten Sind Empfehlungen verletzt, besteht ein erhöhtes Risiko einer schlechten Architektur 4

5 Bewertung von Architekturen Ist die Architektur gut genug? Software Architektur kann nur qualitativ bewertet werden Keine sinnvollen Quantitäten direkt messbar Quantitative Messung möglich von Änderungsumfang und -häufigkeit der Anforderungen Testumfang und -abdeckung Fehlerbehebung während der Implementierung Codemetriken Liefern keine Antwort auf unsere Frage Aber wir haben Response Measures aus den Szenarien! 5

6 Architecture Tradeoff Analysis Method (ATAM) 6

7 Analyse als Voraussetzung der Bewertung Immer wenn eine Schlüssel-Entscheidung getroffen wird oder ein Meilenstein erreicht wird, sollten die gewählte(n) Entscheidungen und mögliche Alternativen analysiert werden Wichtigkeit der Entscheidung Anzahl möglicher Alternativen "Gut genug" im Vergleich zu "Perfekt" Analysekosten sollten Kosten einer Fehlentscheidung nicht übersteigen Gedankenexperimente, Simulationen, Prototypen 7

8 ATAM Evaluatoren müssen die Architektur nicht kennen Das System muss noch nicht existieren Es kann viele Stakeholder geben 3 Gruppen von Beteiligten 1. Evaluatoren: ausserhalb des Projektes, ATAM Experten 2. Projektentscheider: Architekt, projekt owner, product owner 3. Architektur Stakeholder: Haben ein Interesse an einer funktionierenden Architektur Formulieren die Qualitätsattribute, die das System für sie zu einem Erfolg macht (Entwickler, Tester, Benutzer) bei grossen Systemen 8

9 Geschäftsziele und Rahmenbedingungen Funktionale und Nichtfunktionale Anforderungen Qualitätsbaum (utility tree) Aktueller Architektur-Entwurf Szenarios ATAM Risiken und Nicht-Risiken Sensible Punkte und Kompromisse Risikoanalyse als Ziel Einen Zusammenhang finden zwischen den Architekturentscheidungen und dem zu erwartenden Systemverhalten 9

10 Ergebnisse von ATAM 1. Eine präzise und verständliche Darstellung der Architektur kann in einer Stunde präsentiert werden 2. Formulierung der Geschäftsziele 3. Priorisierte Anforderungen der Qualitätsattribute in Form von Szenarien 4. Risiken Eine Architekturentscheidung, die negative Auswirkungen auf ein Szenario (das QA) hat, ist ein Risiko Architectural risk mitigation plan 10

11 Ergebnisse von ATAM (Forts.) 5. Risikothemen: Welche systematischen Schwächen in der Architektur (oder auch im Team oder im Prozess) führen zu den Risiken? 6. Beziehung der Architekturentscheidungen zu den Qualitätsattributen Welche Entscheidungen stützen welche Qualitäten? 7. Sensible Punkte und Kompromisse Architekturentscheidungen mit Auswirkungen auf eine oder mehrere Qualitätsattribute 11

12 ATAM Qualitätsbaum (Utility Tree) Qualitäten wichten Qualitäten Szenarien COTS - Commercial Off The Shelf L,H,M - Low, High, Medium Intervalle: Auftrittswahrscheinlichkeit +Relevanz/Risiko (optional) 12

13 Andere Variante Utility Tree 6 e 13

14 Qualitäten Performance Availability Usability Security Maintainability Portability Reusability Testability Time To Market Cost and Benefits Projected life time Targeted Market Integration with Legacy System Roll back Schedule Sicht des Benutzers Sicht des Entwicklers Sicht des Business 14

15 Szenarien Kurze und präzise Beschreibung der Interaktion eines Stakeholders mit dem System Vom Stimulus zu messbarer Systemreaktion Wichtig: alle Stakeholder einbeziehen Benutzer, Entwickler, Administratoren, Stakeholder bewerten und wählen die wichtigsten Szenarien (ca ) 15

16 Typische Szenarien Erwartete Use cases mit Qualitätsattribut (Verfügbarkeit) "Remote User greift via Web auf die Report DB zu und erwartet eine Systemantwort in weniger als 5 Sekunden." Zu erwartende Änderungen (growth scenarios) "Hinzufügen eines weiteren Portalservers innerhalb einer Woche, um die Antwortzeiten auf unter 2.5 Sekunden zu reduzieren." Kritische Stress-Situationen für das System "Die Hälfte der Server fällt im Betrieb aus, ohne die Verfügbarkeit des Systems zu beeinträchtigen." 16

17 Risiken und Nicht-Risiken (Risks/Non-Risks) Architekturentscheidungen, die ein Risiko (oder kein Risiko) für ein gegebenes Qualitätsattribut sind Nicht-Risiken: "Gute" Entscheidungen, die ein Qualitätsattribut stützen "Der Backup der Datenbank stellt ein Risiko für die Performanz des Systems dar, wenn eine hohe Systemleistung mit hohen Kosten verbunden ist." "Der Backup ist kein Risiko bei geringen Kosten für die Systemleistung." 17

18 Sensible Punkte und Kompromisse Sensible Punkte (Sensitivity Points) Architekturentscheidungen, die bei einer geringfügigen Änderung grosse Auswirkungen auf ein Qualitätsattribut haben "Der tägliche Backup der Datenbank ist wichtig für die Zuverlässigkeit des Systems." Kompromisse (Tradeoffs) Architekturentscheidungen, die Auswirkungen auf mehrere Qualitätsattribute haben "Der Backup der Datenbank sichert die Zuverlässigkeit, aber beeinträchtigt die Performanz des Systems." 18

19 Wie verläuft ATAM? 1. Stakeholder zusammenbringen 2. ATAM erklären 3. Business Driver/Kontext für Systementwicklung zusammenfassen 4. Architektur vorstellen - Stile sind wichtig 5. Qualitätsbaum aufbauen a) Attribute hierarchisieren und Bedeutung quantifizieren b) Szenarien definieren und priorisieren 6. Szenarien und Architektur gegenüberstellen 7. Risiken, sensible Punkte, Kompromisse identifizieren 8. Massnahmen definieren Ggf. wiederholen 19

20 Vorteile von ATAM Klärung von nichtfunktionalen Anforderungen und Qualitätsattributen Verbesserte Dokumentation von Architektur und Architekturentscheidungen Intensivierte Diskussion zwischen Stakeholdern Frühe Erkennung von Risiken, wenn früh durchgeführt RISIKO: ATAM ist zeitaufwendig! Gewünschtes Ergebnis Risk Mitigation - Einleitung von Massnahmen zur Reduzierung der Risiken Verbesserte Architektur 20

21 Light-weight ATAM Für kleinere und wenig riskante Projekte Internes kleineres Team 1. ATAM erklären 2. Business Driver/Kontext für Systementwicklung zusammenfassen (15 min) 3. Architektur vorstellen (25 min) 4. Qualitätsbaum aufbauen (Qualitätsbaum + Szenarien existieren, review in 1h) a) Attribute hierarchisieren und Bedeutung quantifizieren b) Szenarien definieren und priorisieren 5. Szenarien und Architektur gegenüberstellen (2-3h) 6. Risiken, sensible Punkte, Kompromisse identifizieren (in Schritt 5) 7. Ergebnisse dokumentieren (0.5 h) 21

22 Aufgabe K9: Architekturbewertung I. Erarbeiten Sie einen einfachen Qualitätsbaum mit ca. 3-5 Kriterien und 2-3 Szenarien für das Kolumbus Projekt. II. Identifizieren Sie mindestens ein Risiko und einen Kompromiss in Ihren Architekturentscheidungen. 22

23 Arbeitsfragen 1. Worin bestehen die Herausforderungen beim Architekturentwurf? 2. Nennen Sie Beispiele für Empfehlungen für den Architekturentwurf. 3. Wann analysieren und bewerten Sie eine Architektur? 4. Womit können Sie Architekturen analysieren? 5. Womit können Sie Architekturen bewerten? 6. Erläutern Sie die Grundideen von ATAM. 7. Welche Rolle spielen Szenarien im ATAM Utility Tree? 8. Was verstehen wir in ATAM unter Risiken, Nicht-Risiken, sensiblen Punkten und Kompromissen? 23

24 Arbeitsfragen (Forts.) 9. Warum analysieren + dokumentieren wir welche Architekturentscheidungen welche Qualitätsattribute beeinflussen? 10.Was erhalten wir als Ergebnis von ATAM? 11.Worin sehen Sie Vorteile/Nachteile von ATAM? 12.Wie würden Sie ATAM verwenden, um 2 alternative Architekturentwürfe miteinander zu vergleichen? 13.Sie sollen die Architektur eines Systems überprüfen. Der Architekt ist nicht verfügbar und Sie dürfen auch nicht mit Stakeholdern reden. Was machen Sie? 14.Wann wenden Sie ATAM voll oder lightweight an? 15.Was bekommen Sie von ATAM nicht? 24