Embed Size (px)
Citation preview
Qualitätsattribute und Software-Architektur
Christian Gebhardt
Manuel Hertlein
2
Einführung geschäftliche Überlegungen bestimmen Qualitätsattribute, was
in die Systemarchitektur eingepasst werden muss Qualitätsattribute sind der Teil der Funktionalität, der die
grundlegenden Aussagen über die Fähigkeiten, Dienste und das Verhalten eines Systems macht
Funktionalität nimmt eigentlich die Hauptrolle bei der SW Entwicklung ein
Systeme werden oft redesigned, nicht weil sie die Funktion nicht erfüllen, sondern weil sie zu langsam, schwierig zu warten, zu portieren und zu skalieren bzw. anfällig für Hackerangriffe sind
3
Einführung
Architektur ist die erste Stufe der SW Entwicklung, zu der sich Qualitätsanforderungen zuordnen lassen
dies geschieht durch Übertragung der System Funktionalität auf Software Strukturen, die die Unterstützung der Architektur für Qualitätsattribute bestimmt
bei unserer weiteren Betrachtung konzentrieren wir uns auf das Verständnis, wie man Qualitätsattribute beschreibt, die die Architektur dem System bereitstellen soll
4
Funktionalität und Architektur
Funktionalität ist die Fähigkeit eines Systems die Aufgabe zu erfüllen für die es erstellt wurde
eine Aufgabe erfordert, das die Elemente des Systems in koordinierter Weise zusammen arbeiten um sie zu lösen
Funktionalität ist mit verschiedensten Strukturen erreichbar, d.h. sie ist größtenteils unabhängig von der Struktur
SW Architektur bedarf aber der Zuweisung zu einer Struktur, wenn Qualitätsattribute erzielt werden sollen
5
Funktionalität und Architektur
Funktionalität und Qualitätsattribute sind orthogonal wären sie nicht orthogonal würde die Wahl der Funktion den
Grad der Qualitätsattribute bestimmen es ist aber möglich den gewünschten Grad jedes Attributes
unabhängig zu wählen zu beachten ist, dass nicht jeder Grad eines Qualitätsattributes
durch jede Funktion zu erzielen ist
6
Architektur und Qualitätsattribute
das Erzielen von Qualitätsattributen muss durchgehend vom Design, über die Implementation bis hin zur Inbetriebnahme betrachtet werden
dabei schließen Qualitätsattribute meist architekturelle Aspekte und nicht-architekturelle Aspekte ein
7
Architektur und Qualitätsattribute
Zwei wesentlichen Aspekte hinsichtlich Architektur und Qualitätsattribute:
1. Zur Realisierung vieler Qualitätsattribute eines Software-Systems ist Architektur nur bedingt verwendbar. Sie sollten eingearbeitet werden und auf der Ebene der Architektur abgeschätzt werden.
2. Architektur allein ist nicht in der Lage Qualitätsattribute zu erzielen, sie bildet zwar die Grundlage dafür, das nützt aber nichts, wenn nicht auf die Details geachtet wird
8
Architektur und Qualitätsattribute
in komplexen Systemen werden Qualitätsattribute niemals einzeln erreicht
das Erzielen eines Attributes hat immer auch einen Effekt auf das Erzielen anderer Attribute
Im Folgenden drei Klassen von Qualitätsattributen1. System Qualitätsattribute
2. Business Qualitätsattribute
3. Architektur Qualitätsattribute
9
Qualitätsattribute eines Softwaresystems Probleme:
Definitionen von Attributen sind nicht operational Zuordnung eines bestimmten Aspekts zu einem Qualitätsattribut Unterschiedliche Vokabulare
Lösung: Benutzung von Qualitätsattributszenarien um die
Qualitätsattribute zu charakterisieren Diskussion über die einzelnen Attribute um fundamentale
Konzepte zu veranschaulichen und Begriffe zu klären
10
Szenarien für Qualitätsattribute Teile eines Szenarios für Qualitätsattribute
Artifact
Stimulus Response
Environment
Response Measure
Source of Stimulus
11
Szenarien für Qualitätsattribute Unterscheidung zwischen
Allgemeinen Szenarien für Qualitätsattribute Konkreten Szenarien für Qualitätsattribute
Charakterisierung von Attributen = Sammlung von allgemeinen Szenarien
Anforderungen für ein bestimmtes System bestimmen: relevante allgemeine Szenarien systemspezifisch machen
12
Beispiel: Verfügbarkeitsszenario Teile eines Szenarios für Qualitätsattribute
Artifact: - Process - Storage - Processor - Communication
Stimulus: - Fault - Omission - Crash - Timing - Response
Response: - Record - Notify - Disable - Continue - (Normal/ Degraded) - Be Unavailable
Environment: - Normal - Degraded - Operation
Response Measure: - Repair - Time - Availability - Available/ Degraded - Time Interval
Source: - Internal - External
13
Beispiel: Verfügbarkeitsszenario „Eine unerwartete externe Nachricht wird von einem Prozess
empfang, der sich im normalen Betrieb befindet. Der Prozess informiert den Operator über den Empfang der Nachricht und fährt ohne Ausfallzeit mit seiner Abarbeitung fort.“
Artifact: Process Stimulus:
Unanticipated message
Response: Inform operator Continue to operate
Environment: Normal Operation
Response Measure: No downtime
Source: External to system
14
Szenarien für Qualitätsattribute nicht jedes systemspezifische Szenario hat sechs Teile
Ergebnis der Applikation wichtig um Anforderungen für Qualitätsattribut zu bestimmen
Quelle des Stimulus wichtig unterschiedliche Antworten auf unterschiedliche Quellen
Umgebung hat ebenfalls Einfluss auf Antwort
Artefakt nicht unbedingt wichtig, aber erwähnt da Viele Anforderungen Annahmen über Interna eines Systems
machen Artefakt kann in weiteren Entwicklungsphasen verfeinert werden,
um genaue Stellen der Stimulation zu spezifizieren
15
Szenarien für Qualitätsattribute Sammlung von konkreten Szenarien Beschreibung von
Anforderungen
Szenarien konkret, aussagekräftig für Architekt Antworten aussagekräftig, um ein System daraufhin testen zu
können
16
Generierung von SzenarienQualitätsattribut-spezifischen Tabellen
allgemeine Szenarien
System-spezifische Szenarien
Für jedes Attribut wird eine Tabelle angegeben, die die möglichen systemunabhängigen (!) Werte für jeden der sechs Teile eines Qualitätsszenarios angibt
17
Generierung von SzenarienQualitätsattribut-spezifischen Tabellen
allgemeine Szenarien
System-spezifische Szenarien
Für jedes Element eines Qualitätsszenarios wird ein möglicher Wert ausgewählt
Szenarien sind immer noch systemunabhängig
18
Generierung von SzenarienQualitätsattribut-spezifischen Tabellen
allgemeine Szenarien
System-spezifische Szenarien
System-spezifische Szenarien aus allgemeinen Szenarien abgeleiten
Resultat wird „lesbar“ gemacht
19
Generierung von Szenarien Es werden nicht alle möglichen Szenarien generiert
Tabellen dienen nur als Checklisten
Bei Beseitigung von Redundanzen (wenn z.B. zwei Attribute die gleichen Anforderungen generieren) ist sicherzugehen, dass kein wichtiges Qualitätsattribut entfernt wird ernsthafte Konsequenzen auf System
Konkrete Szenarien spielen in Spezifikation der Anforderungen der Qualitätsattribute dieselbe Rolle wie Use Cases für die Spezifikation der funktionalen Anforderungen
20
Anwendung von Szenarien für Qualitätsattribute allgemeine Szenarien stellen Framework für die Generierung
vieler allgemeiner, system-unabhängiger, für Qualitätsattribute spezifische Szenarien zu Verfügung
jedes ist anwendbar, aber nicht unbedingt relevant für ein betrachtetes System
allgemeine Szenarien müssen systemspezifisch gemacht werden um sie für spezielle Systeme anzuwenden
dies geschieht durch die Übersetzung in konkrete Ausdrücke des betrachteten Systems
außerdem kann ein einzelnes allgemeines Szenario auch mehrere systemspezifische Ausprägungen haben
21
Verfügbarkeit Betrachtung von Systemfehlern und ihren Konsequenzen Systemfehler tritt ein, wenn das System nicht länger einen
Service anbietet, der mit der Spezifikation übereinstimmt solche Fehler sind durch die Benutzer erkennbar Felder der Betrachtung:
Wie wird Systemfehler entdeckt? Wie oft tritt er auf? Was passiert wenn er auftritt? Wie lange darf ein System außer Betrieb sein? Welche Fehlermeldungen sind nötig wenn ein Fehler auftritt?
22
Verfügbarkeit
Unterscheidung zwischen Systemfehlern und Fehlern Fehler kann zum Systemfehler werden, wenn er nicht
korrigiert oder maskiert wird Ein Systemfehler kann durch den Benutzer erkannt werden,
ein Fehler aber nicht Wird ein Fehler erkennbar wird er zum Systemfehler
23
Verfügbarkeit
wenn ein Systemfehler erstmal aufgetreten ist, interessiert die Dauer bis das System repariert ist
die Verfügbarkeit eines Systems ist dann die Wahrscheinlichkeit, dass das System betriebsbereit ist wenn es gebraucht wird
Damit ergibt sich die Definition:
Reparaturzur bis Zeit ern Systemfehlzwischen Zeit
ernSystemfehlzwischen Zeit
24
Allgemeines VerfügbarkeitsszenarioPortion of Scenario Possible Values Source Internal to the system; external to the system Stimulus Fault: omission, crash, timing, response Artifact System’s processors, communication channels, persistent storage,
processes Environment Normal operation;
degraded mode (i.e. fewer features, a fall back solution) Response System should detect event and do one or more of the following:
- record it - notify appropriate parties, including the user and other
systems - disable sources of events that cause fault or failure according
to defined rules - be unavailable for a prespecified interval, where interval
depends on criticality of system - continue to operate in normal or degraded mode
Response Measure Time interval when the system must be available Availability time Time interval in which system can be in degraded mode Repair time
25
Beispiel: Verfügbarkeitsszenario „Eine unerwartete externe Nachricht wird von einem Prozess
empfang, der sich im normalen Betrieb befindet. Der Prozess informiert den Operator über den Empfang der Nachricht und fährt ohne Ausfallzeit mit seiner Abarbeitung fort.“
Artifact: Process Stimulus:
Unanticipated message
Response: Inform operator Continue to operate
Environment: Normal Operation
Response Measure: No downtime
Source: External to system
26
Allgemeines Modifizierbarkeitsszenario Aufwand der zur Durchführung vorgegebener Änderungen
notwendig ist
Was kann sich ändern (bzw. das Artefakt ändern)? Änderungen können jeden Aspekt des Systems betreffen
Funktionen Plattform Umgebung Qualitäten Kapazität
Änderungen an Plattform = Portabilität
27
Allgemeines Modifizierbarkeitsszenario Wann wird eine Änderung vorgenommen und von wem?
Änderungen können vorgenommen werden während der Implementation des Kompilierens des Buildens der Konfiguration der Ausführung
Änderungen können durchgeführt werden von Entwickler Systemadministrator Endbenutzer
28
Allgemeines Modifizierbarkeitsszenario
Portion of Scenario Possible Values Source End user, developer, system administrator Stimulus Wishes to add/delete/modify/vary
functionality, quality attribute, capacity Artifact System user interface, platform, environment;
system that interoperates with target system Environment At runtime, compile time, design time Response Locates places in architecture to be modified;
makes modification without affecting other functionality; tests modification; deploys modification
Response Measure Cost in terms of number of elements affected, effort, money; extent to which this affects other functions or quality attributes
29
Beispiel: Modifizierbarkeitsszenario „Ein Entwickler möchte ein UI ändern. Die Veränderung
findet in der Design Phase statt und wird direkt am Code vorgenommen. Der Vorgang soll max. 3 Stunden dauern und keine Nebeneffekte auf das Systemverhalten haben.“
Artifact: Code Stimulus:
Wishes to change the UI
Response: Modification is made with no side effects
Environment: At design time
Response Measure: In 3 hours
Source: Developer
30
Performance ist der Grad zu dem ein System oder eine Komponente eine
bestimmte Funktion innerhalb besonderer Parameter wie z.B. Geschwindigkeit, Pünktlichkeit oder Speichernutzung ausführt
für die Reaktion auf einen Stimulus verweist Performance beispielsweise auf die benötigte Zeit oder die Anzahl der im Zeitintervall bearbeiteten Events
die Anzahl der Event Source und Arrival Patterns sind Beispiele, die Performance kompliziert machen
Quellen von Events: Benutzeranfragen Andere Systeme System selbst
31
Performance ein Performance Szenario beginnt mit der Ankunft einer
Anfrage an einen Service beim System um diese zu erfüllen müssen Ressourcen konsumiert werden,
gleichseitig können auch schon die nächsten Anfragen bearbeitet werden
Ankunftsmuster für Events werden entweder als periodisch oder als stochastisch charakterisiert
Events können auch sporadisch ankommen(nicht periodisch oder stochastisch)
viele Benutzer oder andere Ladefaktoren können durch unterschiedliche Ankunftsmuster von Events modelliert werden
32
Performance
Die Antworten eines Systems auf einen Stimulus können charakterisiert werden als:
Verzögerung Deadlines in der Verarbeitung Durchsatz Anzahl der nicht verarbeiteten Anfragen wegen
Systemüberlastung und dem entstehenden Datenverlust
33
Allgemeines Performanceszenario
Portion of Scenario Possible Values Source One of a number of independent sources,
possibly from within system Stimulus Periodic events arrive; sporadic events arrive;
stochastic events arrive Artifact System Environment Normal mode; overload mode Response Processes stimuli; changes level of service Response Measure Latency, deadtime, throughput, jitter, miss
rate, data loss
34
Beispiel: Performanceszenario „Benutzer initiieren stochastisch 1000 Transaktionen pro
Minute in normalem Bearbeitungsmodus. Diese Transaktionen werden mit einer durchschnittlichen Verzögerung von 2 Sekunden bearbeitet.“
Artifact: System Stimulus:
Initiate transactions
Response: Transactions are processed Environment:
Under rormal operations
Response Measure: With average latency of two seconds
Source: User
35
Allgemeines Sicherheitsszenario Fähigkeit nicht autorisierten Zugriff – ob zufällig oder
absichtlich – auf Daten und Services zu verhindern und dabei gleichzeitig noch Dienste den legitimen Benutzern zu Verfügung zu stellen
Formen von Attacken: Unautorisierter Versuch Zugriff auf Daten oder Services zu
erhalten Modifizieren von Daten Deny of Service
36
Allgemeines Sicherheitsszenario Aspekte, die ein System bereitstellen muss, um den
Anforderungen für die Sicherheitsqualitätsattribute zu erfüllen:
Nonrepudiation (Nicht-Nichtanerkennung) Transaktion kann von einer beteiligten Person nicht abgestritten
werden, wenn sie von ihr durchgeführt wurde
Vertraulichkeit Daten und Services sind vor unautorisiertem Zugriff geschützt
Integrität Daten und Services werden so bereitgestellt, wie beabsichtigt
37
Allgemeines Sicherheitsszenario Versicherung
Parteien, die an einer Transaktion teilnehmen sind die, die sie vorzugeben zu sein
Verfügbarkeit System ist für legitime Benutzung verfügbar
Auditing System verfolgt Tätigkeiten, die in ihm von statten gehen und
zeichnet sie in einem gewissen Abstraktionsniveau auf, so dass sie später rekonstruiert werden können
38
Allgemeines Sicherheitsszenario
Portion of Scenario Possible Values Source Individual or system that is
- correctly identified, identified incorrectly, of unknown identity
who is - internal/external, authorized/not
authorized with access to
- limited resources, vast resources Stimulus Tries to
- display data, change/delete data, access system services, reduce availability to system services
Artifact System services; data within system Environment Either
- online or offline, connected or disconnected, firewall or open
39
Allgemeines SicherheitsszenarioPortion of Scenario Possible Values Response Authenticates user; hides identity of the user;
blocks access to data and/or services; allows access to data and/or services; grants or withdraws permission to access data and/or services; records access/modifications or attempts to access/modify data/services by identity; stores data in an unreadable format; recognizes an unexplainable high demand for services, and informs a user or another system, and restricts availability of services
Response Measure Time/effort/resources required to circumvent security measures with probability of success; probability of detecting attack; probability of identifying individual responsible for attack or access/modification of data and/or services; percentage of services still available under denial-of-services attack; restore data/services; extent to which data/services damaged and/or legitimate access denied
40
Beispiel: Sicherheitsszenario „Ein korrekt identifiziertes Individuum versucht Systemdaten
von einer externen Seite zu modifizieren. Das System vermerkt es in einem audit trail und die korrekten Daten werden innerhalb eines Tages wieder restauriert.“
Artifact: Data within the system
Stimulus: Tries to modify information
Response: System maintains audit trail Environment:
Under normal operations
Response Measure: Correct data is restored within a Day
Source: Correctly identified individual
41
Testbarkeit Testbarkeit ist die Möglichkeit, zum Testen eines Systems
hinsichtlich Korrektheit, Robustheit und Zuverlässigkeit großer Teil der Kosten für SW Entwicklung wird durch
Testen verursacht wenn man diese Kosten senken könnte, würde der Ertrag
steigen damit ein System richtig testbar ist, muss man den Zustand
und die Eingaben jeder Komponente kontrollieren können und auch die Ausgaben überwachen können
42
Testbarkeit
dies wird oft durch die Benutzung von Testsoftware erreicht Teile des Codes, das Design oder das ganze System können
getestet werden
43
Allgemeines TestbarkeitszenarioPortion of Scenario Possible Values Source Unit developer
Increment integrator System verifier Client acceptance tester System user
Stimulus Analysis, architecture, design, class, subsystem integration completed; system delivered
Artifact Piece of design, piece of code, complete application
Environment At design time, at development time, at compile time, at deployment time
Response Provides access to state values; provides computed values; prepares test environment
Response Measure Percent executable statements executed Probability of failure if fault exists Time to perform tests Length of longest dependency chain in test Length of time to prepare test environment
44
Beispiel: Testbarkeitszenario „Ein Unit-Tester führt einen Unit-Test einer fertig gestellten
Komponente durch, die eine Schnittstelle zur Kontrolle ihres Verhaltens und zur Beobachtung ihrer Ausgaben bereitstellt. Dabei soll 85% Pfadabdeckung in 3 Stunden erreicht werden.“
Artifact: Component of the system
Stimulus: Performs unit test
Response: Component has interface for controlling behavior and output of the component is obervable
Environment: At the completion of the component
Response Measure: Path coverage of 85% is achieved within 3 hours
Source: Unit tester
45
Allgemeines Usabilityszenario Wie einfach ist es für einen Benutzer, eine gewünschte
Aufgabe durchzuführen? Welche Art von Unterstützung erhält der Benutzer durch das
System?
verschiedener Aspekte: Erlernbarkeit Effizienz Fehlertoleranz Anpassbarkeit Vertrauen und Zufriedenheit
46
Allgemeines UsabilityszenarioPortion of Scenario Possible Values Source End user Stimulus Wants to
- learn system features; use system efficiently; minimize impact of errors; adapt system; feel comfortable
Artifact System Environment At runtime or configure time Response System provides one or more of the following
responses: to support “learn system features” - help system is sensitive to context;
interface is familiar to user; interface is usable in an unfamiliar context
to support “use system efficiently” - aggregation of data and/or commands;
re-use of already entered data and/or commands; support for efficient navigation within screen; distinct views with consistent operations; comprehensive searching; multiple simultaneous activities
47
Allgemeines Usabilityszenario
Portion of Scenario Possible Values Response (cont.) to “minimize impact of errors”
- undo, cancel, recover from system failure, recognize and correct user error, retrieve forgotten password, verify system resources
to “adapt system” - customizability; internationalization to “feel comfortable” - display system state; work at the user’s
pace Response Measure Task time, number of errors, number of
problems solved, user satisfaction, gain of user knowledge, ratio of successful operations to total operations, amount of time/data lost
48
Beispiel: Usabilityszenario „Ein Benutzer möchte, um die Auswirkung eines Fehlers zu
verringern, eine Systemoperation während der Laufzeit abbrechen. Der Abbruch benötigt weniger als 2 Sekunden statt.“
Artifact: System Stimulus:
Minimize impact of errors
Response: Wishes to cancel current operations Environment:
At runtime
Response Measure: Cancellation takes less than 1 second
Source: User
49
Kommunikationskonzepte
eine Anwendung von allgemeinen Szenarien ist das Ermöglichen der Kommunikation zwischen Außenstehenden
jede Attributfamilie hat eigenes Vokabular um grundlegende Konzepte zu beschreiben
die unterschiedlichen Ausdrücke können aber das selbe Ereignis darstellen -> Verständigungsprobleme
folglich hilft eine Erleichterung dieser Art von Verständnis Diskussionen über Architektur Entscheidungen zu verbessern, besonders die über Tradeoffs
50
Stimuli von QualitätsattributenQuality Attribute Stimulus Availability Unexpected event, nonoccurence of expected
event Modifiability Request to add/delete/change/vary
functionality, platform, quality attribute, or capacity
Performance Periodic, stochastic, or sporadic Security Tries to
- display, modify, change/delete information, access, or reduce availability to system services
Testability Completition of phase of system development Usability Wants to
- learn system features; use system efficiently; minimize impact of errors; adapt system; feel comfortable
51
Kommunikationskonzepte Manche Stimuli treten während der Laufzeit auf andere schon
davor Es ist schwer zu verstehen welche Stimuli das selbe Ereignis
darstellen, welche Stimuli Zusammenfassungen andere Stimuli sind und welche Stimuli unabhängig sind
Wenn diese Beziehungen erst einmal klar sind kann sich ein SW Architekt mit Außenstehenden in einer Sprache verständigen die jeder verstehen
Man kann keine allgemeine Aussage über die Beziehung zwischen den Stimuli machen, da sie teilweise vom Environment abhängen
52
Andere System Qualitätsattribute
Skalierbarkeit Portabilität wenn ein anderes Qualitätsattribut für die eigene Organisation
wichtig ist, wäre es vernünftig eigene allgemeine Szenarien dafür zu kreieren
dies beinhaltet das Ausfüllen der 6 Teile des Frameworks zur Generierung von Szenarien
53
Business Qualities Time to market
Entwicklungszeit durch Konkurenzdruck oder schmales Zeitfenster gering
Einkauf und/oder Wiederverwendung existierender Elemente Einbindung abhängig von Dekomposition
Kosten und Gewinn Entwicklungsprozess darf Budget nicht überschreiten Unterschiedliche Architekturen führen zu unterschiedlichen
Entwicklungskosten
54
Business Qualities Geplante Lebenszeit eines Systems
Lebenszeit eines Systems steht in enger Wechselwirkung mit Modifizierbarkeit, Skalierbarkeit und Portabilität
Angezielter Markt Plattform und Features eines Systems bestimmen Größe des
potenziellen Marktes Portabilität und Funktionalität wichtige Aspekte Produktlinie sollte gemeinsamen Kern besitzen der
Grundeigenschaften des Systems bereitstellt
55
Business Qualities Rollout Schedule
Produkt soll mit Basisfunktionalität veröffentlicht und um zahlreiche Features in späteren Releases erweitert werden Flexibilität und Anpassbarkeit der Architektur
Integration von Legacy Systems System soll in ein existierendes System integriert werden
passende Integrationsmechanismen definieren vor allem durch Marketing-Abteilung gewünscht
56
Architekturqualitäten Begriffsintegrität
Vereinigung des Designs eines Systems auf allen Ebenen Architektur soll ähnliche Dinge auf ähnliche Art und Weise tun
Korrektheit und Vollständigkeit
Buildability System kann rechtzeitig von einem verfügbaren
Entwicklungsteam fertig gestellt werden Focus auf Dekomposition eines Systems Ziel: maximale Parallelität im Entwicklungsprozess Weiterer Aspekt: Wissen über ein zu lösendes Problem
57
Literatur
Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, 2nd Ed, Addison-Wesley 2003.
