Kapitel 11: Bewertung von Softwarearchitekturen - Vorlesung Softwarearchitektur | Wintersemester 2019/20 - Architekturbewertung ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Vorlesung Softwarearchitektur | Wintersemester 2019/20 Kapitel 11: Bewertung von Softwarearchitekturen Architekturbewertung | Basistechniken und Methoden | ATAM | CBAM | FTA Thorsten Weyer
Lernziele
Die Studierenden
• kennen die Qualitätskriterien zur Bewertung von Software-Architekturen
• können die Einordnung der Architekturbewertung im Entwicklungs- und Lebenszyklus erläutern
• kennen die Basistechniken zur Architekturbewertung und können diese situationsabhängig auswählen
• kennen die Methoden zur Architekturbewertung und können diese situationsabhängig auswählen
• können ATAM-basierte Architekturbewertungen durchführen
• können die Einordnung und Durchführung von CBAM-basierten Kosten-Wert-Analysen erläutern
• können die Einordnung und Durchführung Gefährdungsanalysen erläutern
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 2Gliederung Grundlegende Aspekte der Bewertung von Software-Architekturen Architekturbewertung im Entwicklungsprozess bzw. Lebenszyklus Basistechniken und Methoden zur Architekturbewertung Architecture Tradeoff Analysis Method (ATAM) Kosten-Wert-Analyse (am Bsp. CBAM) und Gefährdungsanalysen (am Bsp. FTA) Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 3
Begriff „Architekturbewertung“ | Definition
“Software architecture evaluation is an important activity in the software architecting
process. The fundamental goal of architecture evaluation is to assess the potential of a
proposed/chosen architecture to deliver a system capable of fulfilling required quality
requirements and to identify any potential risks.”
Quelle: Paul Clements, Rick Kazman, Mark Klein: Evaluating Software
Architecture - Methods and Case Studies- Addison-Wesley Professional, 2002.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 4Begriff „Architekturbewertung“ | Definition
Merke: Die Architekturbewertung besitzt zwei Betrachtungsgegenstände:
1) Bewertung der Architekturspezifikation (als Entwicklungsartefakt)
im Hinblick auf geforderte Spezifikationsqualitäten (z.B. Lesbarkeit, Verständlichkeit,
Widerspruchfreiheit, Vollständigkeit, Konformität zu Spezifikationsvorgaben)
2) Bewertung der in der Architekturspezifikation dokumentierten Softwarearchitektur im
Hinblick darauf, ob notwendige Funktionalitäten, Qualitäten und Randbedingungen durch die
Architektur erfüllbar sind (Architekturbewertung im engeren Sinne)
3) 1) ist Voraussetzung für 2)
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 5Grundlegendes Qualitätskonzept (1)
Systemanforderungen System
Systemerstellung
Qualitätsanforderungen
Qualitätsanforderungen Qualitätsanforderungen
Qualitätsanforderungen
Qualitätsanforderungen Qualitätseigenschaften
Qualität
qualifiziert ein qualifiziert ein
Qualitätsanforderungen
Qualitätsmerkmal
Qualitätsanforderungen
(Sicherheit, Zuverlässigkeit, …)
Ralf Reussner, Wilhelm Hasselbring (Hrsg.): Handbuch der
Software-Architektur. 2. Auflage, Dpunkt Verlag 2009. Kapitel 13
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 6Architekturbewertung | Kategorien von
Qualitätsmerkmalen
Auswahl
Generell
• Funktionale Sicherheit („Safety“)
• Verfügbarkeit
• Zuverlässigkeit
• Wartbarkeit
• Performance
• Sicherheit („Security“)
• Änderbarkeit
• Erweiterbarkeit
• Ökonomie Quelle: ISO/IEC 25010:2011
• Konzeptionelle Integrität
• Portierbarkeit
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 7Konzeptionelle Integrität (1)
Konzeptionelle Integrität ist die Qualität eines System in Bezug auf den Umfang, indem
alle Konzepte und deren Beziehungen zueinander auf konsistente Art und Weise
angewendet sind.
“I will contend that conceptual integrity is the most important consideration in system design. It is
better to have a system omit certain anomalous features and improvements, but to reflect one set
of design ideas, than to have one that contains many good but independent and uncoordinated
ideas.“
[…] "Conceptual integrity in turn dictates that the design must proceed from one mind, or from a
very small number of agreeing resonant minds."
Quelle: Frederick P. Brooks: The Mythical Man-Month. Essays on Software
Engineering Addison-Wesley Longman; 1975 (Erstausgabe).
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 8Konzeptionelle Integrität (2)
"... the most important action is the commissioning of some one mind to be the product's architect,
who is responsible for the conceptual integrity of all aspects of the product perceivable by the user.“
[…]
"For quite large products, one mind cannot do all of the architecture, even after all implementation
concerns have been split off. So it is necessary for the system master architect to partition the system
into subsystems. The subsystem boundaries must be at those places where interfaces between the
subsystems are minimal and easiest to define rigorously. Then each piece will have its own architect,
who must report to the system master architect with respect to the architecture."
Quelle: Frederick P. Brooks: The Mythical Man-Month. Essays on Software
Engineering Addison-Wesley Longman; 1975 (Erstausgabe).
Konzeptionelle Integrität beruht auf klaren Prinzipien!
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 9Architekturbewertung im Entwicklungsprozess
| Schema
Entwurfsentscheidungen: E1, …. En
Architekturentwurfsphase z.B. Qualitätsattributszenarien
Qualitätsanforderungen
Qualitätsanforderungen
Qualitätsanforderungen Qualitätsanforderungen
Qualitätsanforderungen
Architekturspezifikation
Verbesserungsvorschläge Verbesserungsvorschläge
Architekturbewertung
OK
Architekturabnahme In Anlehnungen an: Ralf Reussner, Wilhelm Hasselbring
(Meilenstein) (Hrsg.): Handbuch der Software-Architektur, 2. Auflage,
dpunkt-Verlag, Heidelberg, 2009
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 10Architekturbewertung | Aussagekraft des
Ergebnisses
Implementierung
Architekturspezifikation System
definiert besitzt
Vorhersage
Architektureigenschaften Qualitätseigenschaften
Achtung: Gilt nur unter gewissen
Annahmen! ( siehe nächste Folie) In Anlehnung an: Ralf Reussner, Wilhelm Hasselbring
(Hrsg.): Handbuch der Software-Architektur, 2. Auflage,
dpunkt-Verlag, Heidelberg, 2009
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 11Architekturbewertung | Feststellungen
Die Architektur kann die notwendigen Funktionalitäten und Qualitäten im späteren System
1 nicht garantieren!
Mangelhaft durchgeführte Entwicklungsaktivitäten in nachgelagerten Entwicklungsschritten
2 (z.B. Detailentwurf, Implementierung) können die Qualität der Architektur unterminieren.
Architekturbewertung überprüft die Eignung der Architektur dahingehend, ob die Architektur
3 es ermöglicht, dass das entwickelte System die entsprechenden Qualitäten aufweist.
Voraussetzung, dass das System tatsächlich die in Architekturbewertung bestätigten Qualitäten
4 aufweist, ist, dass sämtliche Verfeinerungsschritte der Architektur, bis hin zur Eben der
Implementierung, qualitätserhaltend sind.
Merke: Die Architektur sollte frühzeitig im Rahmen eines formellen Review-Prozesses begutachtet werden.
Nachgelagerte Entwicklungsartefakte (z.B. Detailentwurf, Implementierung) müssen regelmäßig überprüft
werden, um etwaige Verletzungen von Architekturvorgaben festzustellen.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 12Architekturbewertung | Einordnung am Beispiel
der Architekturentwicklung z.B. im RUP
Quelle: Donald G. Firesmith,
Peter Capell, Charles B.
Hammonset al: The Method
Framework for Engineering
System Architectures, Auerbach
Publications, 2008
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 13Architekturevaluation im Lebenszyklus
Lebenszyklus Ausprägung der Architekturbewertung
• Initiale Bewertung nachdem erste Architekturentscheidungen von großer Tragweite getroffen wurden.
Bewertung der initialen Entwurfsentscheidungen z.B. im Hinblick auf kritische Qualitätsanforderungen.
Früh
• Zu diesem Zeitpunkt liegt kein Architekturentwurf vor, sondern lediglich eine Menge von
Architekturentscheidungen.
• Bewertung der Architektur nachdem die Architektur umfangreicher ausgearbeitet ist bspw. auch nach
gewissen Iterationsschritten der Architekturentwicklung.
• Voraussetzung ist ein mehr oder weniger vollständiger Architekturentwurf auf unterschiedlichen
Mittel
Vollständigkeitsgraden.
• Aufdeckung von Qualitätsmängeln bzw. Problemen im Architekturentwurf im Hinblick auf
Qualitätsattribute und ggf. Rahmenbedingungen.
• Bewertung nachdem das System vollständig entworfen und implementiert ist und sich im Wirkbetrieb
befindet.
• Zu diesem Zeitpunkt existiert sowohl die Architekturspezifikation als auch das entwickelte System,
Spät weshalb z.B.: 1) analysiert werden kann, ob die Architektur die aktuelle Implementierung adäquat
widerspiegelt; 2) analysiert werden kann, ob und wenn ja wie die tatsächliche (de facto) Architektur
des entwickelten Systems von der Architekturspezifikation abweicht.
( „Evolution von Softwarearchitekturen“)
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 14Basistechniken in der Architekturbewertung
Beispiele
Merke: Basistechniken zur
Architekturbewertung unterstützen
spezifische Tätigkeiten im
Bewertungsprozess.
Merke: Methoden zur
Architekturbewertung definieren
typischerweise eine kontextabhängige
zweckbezogene Systematik zur Bewertung
Quelle: G. Abowd, L. Bass, P. Clements, R. Kazman, L. von Architekturen unter Einsatz
Northrop, A. Zaremski: Recommended Best Industriel Practice verschiedener Techniken. Der konkrete
for Software Architecture Evaluation. Technischer Bericht Prozess der Architekturbewertung wird
CMU/SEI-96-TR-025, Software Engineering Institut, Carnegie durch die jeweils gewählte Methode
Mellon University, 1996. bestimmt.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 15Einordnung von Basistechniken in den
Entwicklungsprozess (Auswahl)
Requirements Engineering Architekturentwurf Systemkonstruktion
Scope, Kontext, Anforderungen Softwarearchitektur, Detailentwurf SW-Spezifikation, Implementierung, Test
Präsentationen (informelle Bewertung)
Reviews (formellere Bewertung z.B. durch Walkthroughs, Inspektionen)
Prototypen
Szenario-basierte
Bewertung
Skelett-System
Quelle: Nick Rozanski, Eoin Woods: Software Systems Architecture - Working
with Stakeholders Using Viewpoints and Perspectives. Addison-Wesley, 2011.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 16Methoden zur Architekturbewertung
und Qualitätsattribute (Auswahl)
Qualitätsmerkmal
Erweiterbarkeit
Zuverlässigkeit
Portierbarkeit
Verfügbarkeit
Änderbarkeit
Performance
Wartbarkeit
Ökonomie
Sicherheit
Sicherheit
(Security)
(Safety)
X wird unmittelbar unterstützt
SAAM X O/X X X O/X X X O/X X O/X kann unterstützen
ATAM X O/X X X O/X X X X
Methoden
CBAM O/X O/X O/X O/X O/X X O/X
ALMA X
FTA X O/X X
RBD O/X O/X X
In Anlehnung an: Ralf Reussner,
FMEA X Wilhelm Hasselbring (Hrsg.):
HAZOP X Handbuch der Software-
Hip-HOPS X O/X Architektur, 2. Auflage, dpunkt-
Verlag, Heidelberg, 2009
Markov-A. X X O/X
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 17ATAM (Architecture Tradeoff Analysis Method)
• Entwickelt am Software Engineering Institut (SEI) der Carnegie Mellon University (CMU)
• Methode zur Evaluation (Bewertung) von Architekturen komplexer Systeme
• Basiert auf der Annahme, dass die Reviewer zunächst keine (umfassenden)
Informationen über die relevanten Geschäftsziele und die Architektur besitzen
• Diverse Erweiterungen und leichtgewichtige Ansätze verfügbar
• ATAM ist für eine Vielzahl von Anwendungsdomänen geeignet und wurde mehrfach
erfolgreiche eingesetzt:
• Finanzdienstleistungssektor
• Luft- und Raumfahrt
• Automobilbau
• Militärische Systeme
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 18ATAM | Informationsflüsse und Teilnehmer Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 19
ATAM | Wichtige Teilnehmer
• Evaluationsteam (Evaluation team)
• Außerhalb des Projekts, dessen Architektur bewertet wird
• 3-5 Personen, eine Person kann ggf. mehrere Rollen einnehmen
• Kompetenz und Neutralität
• Projektentscheidungsträger (Decision maker)
• Personen, die ermächtigt sind, für das Projekt zu sprechen bzw. die das Mandat haben Änderungen an das
Projektteam weiterzugeben
• Typischerweise: Projektmanager, Auftraggeber (ggf. Produktmanagement), Architekt (obligatorisch)
• Interessenträger bzgl. der Softwarearchitektur (Stakeholder)
• Personen oder Personengruppen, die ein Interesse an der Architektur des Systems haben
• Typischerweise Repräsentanten von: Entwicklung, Test, Systemintegration, Benutzer,
Schnittstellenverantwortliche anderer relevanter Systeme
• Artikulieren spezifische Qualitätsanforderungen an die Architektur
• 12-15 Personen für die Bewertung großer unternehmenskritischer Softwarearchitekturen
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 20ATAM | Rollen
Rolle Verantwortlichkeiten
Teamleiter Aufsetzen der Architekturbewertung, Koordination mit Kunden, Sicherstellung, dass die
Wünsche des Kunden adressiert werden, stellt das Evaluationsteam zusammen, Erstellung
und Übergabe des abschließenden Bewertungsberichts (Erstellung kann delegiert werden).
Evaluationsleiter Führt die Architekturbewertung durch, treibt die Gewinnung von Szenarien voran,
koordiniert den Prozess der Definition und Priorisierung von Szenarien, treibt die Evaluation
der Szenarien gegen die Architektur voran.
Szenario-Schreiber Schreibt während der Gewinnung von Szenarien diese auf Flipcharts / Whiteboards. Hält
abgestimmte Begriffe für jedes Szenario fest und führt die Diskussion zu einem Szenario
weiter bis die zugehörigen Begriffe präzise und abgestimmt vorliegen.
Notizen-Schreiber Erfasst in elektronischer Form Notizen, Ergebnisse etc., z.B. initiale Szenarien, die
Motivation für Szenarien (bzw. Gründe für deren Relevanz) sowie die Ausführung des
Szenarios auf der Architektur; Erstellt z.B. auch Handouts mit geänderten bzw. angepassten
Szenarien für die Teilnehmer.
Fragensteller Bringt Fragestellungen von Architekturbedeutung auf, die typischerweise mit
Qualitätsattributen in Beziehung stehen, bezüglich derer die entsprechende Person
Expertise hat.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 21ATAM | Ergebnisse (1)
• Präsentation der Softwarearchitektur: ca. 1-stündige Präsentation der wesentlichen
Aspekte der Softwarearchitektur
• Explizit gemachte Geschäftsziele („Business Goals“):
• Mitunter werden einigen Teilnehmern die übergeordneten Geschäftsziele erst im
Rahmen des ATAM bewusst. Die Geschäftsziele werden in den Ergebnissen
festgehalten.
• Priorisierte Qualitätsattributanforderungen, die durch Qualitätsattributszenarien
konkretisiert sind
• Aufstellung der Risiken und „Nicht-Risiken“ (Aspekte, für die explizit gemacht ist, dass
diese kein Risiko darstellen):
• Risiko: Entwurfsentscheidung (Architekturentscheidung), die gegebenenfalls zu
unerwünschten Konsequenzen im Hinblick auf Qualitätsattributanforderungen
führt.
• Nicht-Risiken: Entwurfsentscheidung (Architekturentscheidung), die nach einer
durchgeführten Analyse als „sicher“ eingestuft ist.
• Identifizierte Risiken sind die Basis für den Mitigationsplan für Architekturrisiken
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 22ATAM | Ergebnisse (2)
• Risikothemen
• Nach Abschluss der Analyse untersucht das Evaluationsteam die aufgedeckten
Risiken, um übergeordnete Themen zu identifizieren, die systemische
Schwächen in der Architektur, im Prozess des Architekturentwurfs oder im
Team darstellen.
• Werden diese übergeordneten Schwachpunkte nicht behandelt, besteht die
Gefahr, dass Geschäftsziele gefährdet sind.
• Zuordnung von Entwurfsentscheidungen zu Qualitätsanforderungen
• Für jedes betrachtete Qualitätsattributszenario wird der Bezug zu denjenigen
Entwurfsentscheidungen hergestellt, die dazu beitragen, dass das Szenario
vom System realisiert werden kann.
• Sensitivitäts- und Entscheidungspunkten
• Identifikation von Entwurfsentscheidungen, die konkrete Effekte auf eines
oder mehrere Qualitätsattribute haben.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 23ATAM | schwerer fassbare Ergebnisse
• Wichtige, wenngleich weniger fassbare Ergebnisse einer ATAM-
basierten Architekturbewertung:
• Gemeinschaftsgefühl der beteiligten Stakeholder
• Offener unmittelbarer Kommunikationskanal zwischen
Software-Architekten und Stakeholdern
• Gemeinsames Verständnis bei allen Beteiligten bezüglich der
Architektur des Systems und deren Stärken und Schwächen
• Solche Ergebnisse sind typischerweise evident und
langanhaltend in Bezug auf das Problembewusstsein und die
Kommunikationsprozesse
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 24Phasen von ATAM Architekturbewertungen
Phase Aktivität Teilnehmer Typische Dauer
0 Partnerschafft und Vorbereitung: Evaluationsteam, Leitung, Informell durchgeführt
ATAM „Logistik“, Planung, Findung der Entscheidungsträger des nach Bedarf,
richtigen Stakeholder, Formierung des Projekts typischerweise über
Evaluationsteams einen Zeitraum von
mehreren Wochen
1 Durchführung der Evaluation: Schritte 1-6 Evaluationsteam und 1-2 Tage gefolgt von eine
Entscheidungsträger des Pause von 2-3 Wochen
Projekts
2 Durchführung der Evaluation: Schritte 7-9 Evaluationsteam, 2 Tage
Entscheidungsträger,
Stakeholder
3 Nachgelagerte Arbeiten: Erstellung des Evaluationsteam und 1 Woche
Evaluationsberichts und Übergabe, Evaluations-Kunde
Reflektion und Prozessverbesserung
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 25ATAM Phase 1 | Überblick
1 Vorstellung des ATAM
2 Vorstellung des Kontext und der Gründe für die Entwicklung
3 Vorstellung der Architektur
4 Identifikation von Architekturansätzen
5 Erstellung des Utility Tree
6 Analyse der Architekturansätze
Schritt [Nr.]
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 26ATAM Phase 1 | Schritt 1
1 Vorstellung des ATAM • Evaluationsleiter gibt allen Projektrepräsentanten einen
Überblick über ATAM
2 Vorstellung des Kontext und der Gründe für die Entwicklung • Erklärung des Prozesses, dem jeder Beteiligte folgen sollte,
Beantwortung von Fragen und Abstimmung bzgl. des
3 Vorstellung der Architektur
Kontexts und der Erwartungen in Bezug auf die übrigen
Aktivitäten
4 Identifikation von Architekturansätzen
• Typischerweise: basierend auf einer Standardpräsentation
5 Erstellung des Utility Tree beschreibt der Evaluationsleiter die einzelnen Schritte in
ATAM sowie die Ergebnisse der Architekturbewertung
6 Analyse der Architekturansätze
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 27ATAM Phase 1 | Schritt 2
• Jeder Beteiligte der Architekturbewertung sollte den Kontext
1 Vorstellung des ATAM
des betrachteten Systems verstehen sowie die primären
Geschäftsziele (-treiber) für die Entwicklung des Systems
2 Vorstellung des Kontext und der Gründe für die Entwicklung
• Ein Entscheidungsträger im Projekt (idealerweise der
3 Vorstellung der Architektur Projektleiter oder der Kunde) gibt einen Überblick über das
System aus Unternehmenssicht.
4 Identifikation von Architekturansätzen
Aufbau und Inhalte
5 Erstellung des Utility Tree
6 Analyse der Architekturansätze
Quelle: Len Bass, Rick Kazman, Paul Clements: Software
Architecture in Practice. Addison-Wesley, Boston, 2012.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 28ATAM Phase 1 | Schritt 3
• Software-Architekt präsentiert die Architektur
• Präsentation sollte folgendes umfassen:
1 Vorstellung des ATAM • technische Randbedingungen, Hardware, Middleware-
Lösungen die Einsatz finden sollen sowie externe
2 Vorstellung des Kontext und der Gründe für die Entwicklung Systeme
• gewählten Architekturansatz (Architekturstile, /-
3 Vorstellung der Architektur
muster, Taktiken etc.) zur Adressierung der
Anforderungen
4 Identifikation von Architekturansätzen
Aufbau und Inhalte
5 Erstellung des Utility Tree
6 Analyse der Architekturansätze
Quelle: Len Bass, Rick Kazman, Paul Clements: Software
Architecture in Practice. Addison-Wesley, Boston, 2012.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 29ATAM Phase 1 | Schritt 4
• ATAM fokussiert darauf, die Angemessenheit der Architektur
auf Basis des gewählten Architekturansatzes (z.B.
Architekturmuster, Taktiken) zu bewerten
1 Vorstellung des ATAM
• Zu diesem Zeitpunkt hat das Evaluationsteam bereits einen
2 Vorstellung des Kontext und der Gründe für die Entwicklung
guten Überblick über Architekturmuster und Taktiken des
gewählten Architekturansatzes
3 Vorstellung der Architektur • Das Evaluationsteam:
• hat sich mit der Architekturdokumentation
4 Identifikation von Architekturansätzen
auseinander gesetzt
5 Erstellung des Utility Tree • kennt die Präsentation der Architektur (Schritt 3)
• sollte besonders Ansätze in der Architektur
6 Analyse der Architekturansätze
identifizieren, die bisher nicht explizit gemacht wurden
• Das Evaluationsteam katalogisiert die Architekturmuster
und Architekturtaktiken, die es identifiziert hat
• Liste wird allen Beteiligten zugänglich gemacht und über
den Architekturbewertungsprozess hinweg gepflegt
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 30ATAM Phase 1 | Schritt 5
• Die Qualitätsattributanforderungen werden mittels eines
Utility Tree im Detail beschrieben (siehe Vorlesungseinheit
„Entwurf von Softwarearchitekturen III“)
1 Vorstellung des ATAM
• Utility Trees dienen dazu, Anforderungen zu
2 Vorstellung des Kontext und der Gründe für die Entwicklung konkretisieren, in dem präzise die relevanten
Qualitätsanforderungen ausgedrückt werden, die in der
3 Vorstellung der Architektur Architektur entsprechend berücksichtigt sein müssen
(Grundlage sind die Ergebnisse von Schritt 2)
4 Identifikation von Architekturansätzen • In diesem Schritt arbeitet das Evaluationsteam mit den
Entscheidungsträgern zusammen, um die wichtigsten
5 Erstellung des Utility Tree
Qualitätsattributanforderungen zu identifizieren, zu
priorisieren und zu verfeinern.
6 Analyse der Architekturansätze
• Auf der letzten Konkretisierungsebene werden
Qualitätsattributszenarien verwendet (Blätter)
• Abschließend werden die Qualitätsattributszenarien im
Hinblick auf deren Wichtigkeit priorisiert
(z.B. hoch | mittel | gering).
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 31ATAM Phase 1 | Schritt 6 (1)
• Evaluationsteam untersucht die höchstpriorisierten
Qualitätsattributszenarien in sequentieller Reihenfolge
1 Vorstellung des ATAM
• Zu jedem Qualitätsattributszenario wird der Architekt
gebeten Stellung zu nehmen, wie die Architektur dieses
2 Vorstellung des Kontext und der Gründe für die Entwicklung Szenario unterstützt
• Evaluationsteam (insb. der Fragensteller) hinterfragt
3 Vorstellung der Architektur kritisch, die vom Architekten genannten
Architekturentscheidungen
4 Identifikation von Architekturansätzen
• Begleitend dokumentiert das Evaluationsteam die
5 Erstellung des Utility Tree
relevanten Architekturentscheidungen, identifiziert und
katalogisiert deren Risiken, Nicht-Risiken, Sensitivitäten
6 Analyse der Architekturansätze und getroffene Kompromisse
• Typischerweise führt dies zu einer detaillierteren Analyse
• Ziel der Analyse: genügend Architekturinformationen zu
gewinnen, um einen Bezug zwischen
Architekturentscheidungen und den zu erfüllende
Qualitätsattributanforderungen herstellen zu können
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 32ATAM Phase 1 | Schritt 6 (2)
Beispiele
1 Vorstellung des ATAM
• Risiko: Die „Herzschlagfrequenz“ (heartbeat frequency)
beeinflusst die Zeitspanne, in welcher das System eine
2 Vorstellung des Kontext und der Gründe für die Entwicklung
fehlerhafte Komponente detektieren kann. Dies kann ggf. zu
inakzeptablen Reaktionszeiten im Falle einer fehlerhaften
3 Vorstellung der Architektur
Komponente führen.
4 Identifikation von Architekturansätzen • Sensitivität: Die Anzahl simultaner Datenbank-Clients hat
eine Auswirkung auf die Anzahl von Transaktionen, die die
5 Erstellung des Utility Tree Datenbank pro Sekunden ausführen kann.
• Tradeoff: Die „Herzschlagfrequenz“ bestimmt die Zeitspanne,
6 Analyse der Architekturansätze
in der ein Fehlverhalten des Systems detektiert werden kann.
Höhere „Herzschlagfrequenz“ führt zu höherer Verfügbarkeit,
aber verbraucht auch mehr Berechnungszeit, und eine
höhere Bandbreite für die notwendige Kommunikation (was
ggf. die Performance des System negativ beeinflusst).
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 33ATAM Phase 1 | Schritt 6 (3)
1 Vorstellung des ATAM
Dokumentationsvorlage für Architekturansätze
2 Vorstellung des Kontext und der Gründe für die Entwicklung
3 Vorstellung der Architektur
4 Identifikation von Architekturansätzen
5 Erstellung des Utility Tree
6 Analyse der Architekturansätze
Quelle: Len Bass, Rick Kazman, Paul Clements: Software
Architecture in Practice. Addison-Wesley, Boston, 2012.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 34ATAM Phase 1 | Beispiel für ein Analyseergebnis dieser Phase Quelle: Len Bass, Rick Kazman, Paul Clements: Software Architecture in Practice. Addison-Wesley, Boston, 2012. Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 35
ATAM Phase 2 | Überblick
7 Brainstorming und Priorisierung von Szenarien
8 Analyse der Architekturansätze
9 Präsentation der Ergebnisse
Schritt [Nr.]
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 36ATAM Phase 2 | Schritt 7 (1)
• Brainstorming der Stakeholdern hinsichtlich Szenarien, die
eine hohe Aussagekraft bzgl. der spezifischen Rolle des
jeweiligen Stakeholders hat
7 Brainstorming und Priorisierung von Szenarien
• Beispiele:
8 Analyse der Architekturansätze • Wartungsingenieur Szenarien bzgl. der Änderbarkeit
• Benutzer Szenarien bzgl. nützlicher Funktionalität
9 Präsentation der Ergebnisse
oder Einfachheit der Nutzung
• Qualitätsmanager Szenarien bzgl. Testbarkeit des
Systems
• Ziel ist es, auf Basis einer großen Menge von Stakeholdern zu
verstehen, was den Erfolg des Systems ausmachen wird
• Gewonnene Szenarien werden dokumentiert und priorisiert
(z.B. durch Abstimmung)
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 37ATAM Phase 2 | Schritt 7 (2)
Szenarien werden mit den Qualitätsattributszenarien aus
dem Utility Tree verglichen:
7 Brainstorming und Priorisierung von Szenarien
• Weitgehende Überdeckung: Indikator, dass dem
8 Analyse der Architekturansätze
Architekten die Wünsche und Bedürfnisse der
Stakeholder bewusst waren
Präsentation der Ergebnisse
• Größere Diskrepanz: Indikator, dass noch keine
9
ausreichende Übereinstimmung bzgl. der
übergeordneten Ziele zwischen den Stakeholdern
und dem Architekten (Architekturteam) besteht.
Risiko
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 38ATAM Phase 2 | Schritt 8
• Evaluationsteam führt hier die gleiche Aktivität aus wie
in Schritt 6, beginnend bei den höchstpriorisierten neu
entwickelten Szenarien
7 Brainstorming und Priorisierung von Szenarien
• Evaluationsteam unterstützt den Architekten in der
8 Analyse der Architekturansätze
Anwendung der neuen Szenarien auf der Architektur
• Architekt erläutert wie relevante
9 Präsentation der Ergebnisse Architekturentscheidungen dazu beitragen, jedes dieser
Szenarien durch die Architektur zu unterstützen
• Typischerweise werden 5-10 Szenarien in diesem Schritt
betrachtet
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 39ATAM Phase 2 | Schritt 9 (1)
• Evaluationsteam gruppiert (intern) Risiken in
Risikothemen, basierend auf unterschiedlichen Belangen
oder Klassen systemischer Defizite:
• Beispiele:
7 Brainstorming und Priorisierung von Szenarien
• Verschiedene Risiken bzgl. inadäquater bzw. nicht
Analyse der Architekturansätze
aktueller Dokumentation zu geringer Stellenwert
8
der Dokumentation im Projekt
9 Präsentation der Ergebnisse • System ist nicht in der Lage, beim Auftreten von
Systemfehlern noch angemessen zu funktionieren
zu geringer Stellenwert von Rückfallfähigkeiten bzw.
hoher Verfügbarkeit des Systems
• Für jedes Risikothema identifiziert das Evaluationsteam
welche Geschäftstreiber (Schritt 2) davon beeinflusst sind.
• Führt dazu, dass zuvor unentdeckte Risiken von den
Entscheidungsträgern bzw. dem Management
wahrgenommen werden.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 40ATAM Phase 2 | Schritt 9 (2)
• Gesammelte Informationen aus der Architekturbewertung
werden zusammengefast und den Stakeholdern präsentiert.
• Inhalte der Ergebnispräsentation:
7 Brainstorming und Priorisierung von Szenarien
• Dokumentierte Architekturansätze
8 Analyse der Architekturansätze • Menge von Szenarien und deren Priorisierung aus dem
Brainstorming der Stakeholder
9 Präsentation der Ergebnisse
• Der Utility Tree
• Aufgedeckte Risiken
• Dokumentierte Nicht-Risiken
• Sensitivitäts- und Tradeoff-Punkte
• Risikothemen und die Geschäftstreiber, die von diesen
beeinflusst werden
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 41ATAM Aufwand | Erfahrungen aus der Praxis
Beispiel: ATAM für mittelgroße Projekte Beispiel: ATAM für kleine Projekte
Quelle: Paul Clements, Rick Kazman, Mark Klein: Evaluating Software Architectures:
Methods and Case Studies- Addison-Wesley Professional, 2002.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 42CBAM (Cost-Benefit Analysis Method) | Überblick
ATAM + wirtschaftliche Betrachtung von Softwarearchitekturen
(ROI und wirtschaftliche Risiken + deren Mitigation)
Robert L. Nord, Mario R. Barbacci, Paul Clements, Rick Kazman, Mark Klein, Liam O’Brien, James E. Tomayko:
Integrating the Architecture Tradeoff Analysis Method (ATAM) with the Cost Benefit Analysis Method (CBAM).
Technical Note CMU/SEI-2003-TN-038, Software Engineering Institute, Carnegie Mellon University, Boston 2003.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 43Gefährdungsanalyse im Architekturentwurf:
Beispiel: Failure Tree Analysis (FTA) | Überblick
• Failure Tree Analysis (FTA | Fehlerbaumanalyse):
Deduktives Verfahren, welches von einem
TOP-Ereignis
bekannten Gefährdungszustand (Top-Event) ausgeht
und diesen rückwärst zu seinen Ursachen verfolgt.
• FTA bietet sowohl qualitative als auch quantitative
or Ergebnisse:
• Qualitativ: Auflistung von
Ereigniskombinationen, die eine Gefährdung
hervorrufen
A B • Quantitativ: Berechnete
Gefährdungswahrscheinlichkeit eines Systems
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 44Gefährdungsanalyse im Architekturentwurf:
Beispiel: Failure Tree Analysis (FTA) | Überblick
1 Identifikation des TOP-Events
- Single-Point-of-Failure
Fehlerbaum erstellen - Minimales Cut-Set
2
3 Qualitative Analyse
Merke: Berechnung
der Wahrscheinlichkeit
4 Quantitative Analyse
gemäß Kombinatorik
5 Abschlussbericht
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 45Gefährdungsanalyse im Architekturentwurf:
Beispiel: Failure Tree Analysis (FTA) | Überblick
TOP
Modellierungskonstrukte Analyse: Basis-Ereignis A tritt ein!
(Auswahl):
OR Konsequenzen:
Fault Event /
TOP-Event - Aufgrund der Oder-
Intermediate Event Verknüpfung wird Ereignis 1
Ereignis 1 Ereignis 2 eintreten
Basic Event
- Falls Ereignis A oder Ereignis B
OR &
eintreten, tritt auch das TOP-
or OR-Verknüpfung Ereignis ein
- A ist somit ein Single-Point-of-
Ereignis 3 E Failure
A B & AND-Verknüpfung
- A ist auch ein Minimales Cut-
Set
OR
Output- /Input-Port
C D
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 46Gefährdungsanalyse im Architekturentwurf:
Failure Tree Analysis (FTA) | Beispiel
Beispiel
Kein heißes Getränk
Modellierungskonstrukte
(Auswahl):
Kein or Kein
Getränk Strom
Fault Event /
TOP-Event
Intermediate Event
Kein Kaffee &
Basic Event
Keine Milch
Kein
Kaffee- or Kein
pulver Wasser
or OR-Verknüpfung
Keine or Kein
Milch Wasser
& AND-Verknüpfung
Minimales Cut-Set: Minimale Menge von Basisereignissen, deren
gemeinsames Eintreten zu einem Systemausfall führt: {kein Wasser},
Output- /Input-Port {kein Strom}, {kein Kaffeepulver und keine Milch}
Single Point of Failure: {kein Wasser}, {kein Strom}
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 47Zusammenfassung (1) • Architekturbewertung ist der Prozess der Analyse einer (Software-)Architektur im Hinblick darauf, ob ein System, welches auf dieser Architektur beruht, das Potenzial hat, die geforderten Qualitäten zu erfüllen. • Architekturbewertung kann zu verschiedenen Zeitpunkten im Lebenszyklus eines (Software-)Systems mit unterschiedlichen Zielsetzungen durchgeführt werden. • Im Mittelpunkt der Architekturbewertung stehen die notwendigen / geforderten Qualitäten des betrachteten Systems, wie z.B. Performance, Zuverlässigkeit, Verfügbarkeit, aber auch systemimmanente Qualitäten wie z.B. Änderbarkeit, Portierbarkeit. • Ein wichtiges Qualitätskriterium für (Software-)Architekturen ist die Konzeptionelle Integrität ( sollte per Konstruktion sichergestellt werden!) Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 48
Zusammenfassung (2) • Es existieren Basistechniken und Methoden zur Architekturbewertung. Basistechniken sind tendenziell universell. Methoden zur Architekturbewertung zielen oft auf eines oder einige wenige Qualitätskriterien ab. • ATAM (Architecture Tradeoff Analysis Method) gehört zu den bekanntesten praxiserprobten Architekturbewertungsmethoden. Zu ATAM wurden verschiedene Varianten (z.B. leichtgewichtiges ATAM) und Erweiterungen (z.B. CBAM) entwickelt. • Bspw. kann die Architekturbewertung hinsichtlich funktionaler Sicherheit („Safety“) mit Hilfe von Fehlerbäumen (Failure Tree Analysis) bzw. der FMEA (Failure Mode and Effects Analysis) durchgeführt werden. Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 49
Sie können auch lesen
