Qualitätsattribute und Software-Architektur Christian Gebhardt Manuel Hertlein

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

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

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

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

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

Architektur und Qualitätsattribute Zwei wesentlichen Aspekte hinsichtlich Architektur und Qualitätsattribute: 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. 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

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ätsattributen System Qualitätsattribute Business Qualitätsattribute Architektur Qualitätsattribute

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

Szenarien für Qualitätsattribute Teile eines Szenarios für Qualitätsattribute

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

Beispiel: Verfügbarkeitsszenario Teile eines Szenarios für Qualitätsattribute

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.“

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

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

Generierung von Szenarien Qualitä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

Generierung von Szenarien Qualitä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

Generierung von Szenarien Qualitätsattribut-spezifischen Tabellen  allgemeine Szenarien System-spezifische Szenarien System-spezifische Szenarien aus allgemeinen Szenarien abgeleiten Resultat wird „lesbar“ gemacht

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

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

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?

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

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:

Allgemeines Verfügbarkeitsszenario

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.“

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

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

Allgemeines Modifizierbarkeitsszenario

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.“

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

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

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

Allgemeines Performanceszenario

Beispiel: Performanceszenario „Benutzer initiieren stochastisch 1000 Transaktionen pro Minute in normalem Bearbeitungsmodus. Diese Transaktionen werden mit einer durchschnittlichen Verzögerung von 2 Sekunden bearbeitet.“

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

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

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

Allgemeines Sicherheitsszenario

Allgemeines Sicherheitsszenario

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.“

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

Testbarkeit dies wird oft durch die Benutzung von Testsoftware erreicht Teile des Codes, das Design oder das ganze System können getestet werden

Allgemeines Testbarkeitszenario

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.“

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

Allgemeines Usabilityszenario

Allgemeines Usabilityszenario

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.“

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

Stimuli von Qualitätsattributen

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

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

Business Qualities Time to market Kosten und Gewinn 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

Business Qualities Geplante Lebenszeit eines Systems Angezielter Markt 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

Business Qualities Rollout Schedule Integration von Legacy Systems 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

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

Literatur Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, 2nd Ed, Addison-Wesley 2003. 