Architektur und Qualität Seminar Software-Analyse WS 04/05 Daniel Zaum <mail@cowhen.org>
Gliederung Architektur Definitionen Motivation Einordnung des Themas Einleitung Qualität Anforderungen Architekturstile 5 Typen Eigenschaften Hauptteil Beispiel Anwendung Zusammenhang Qualität/Architektur Zusammenfassung 2
Einordung des Themas Qualität Fordert Bestimmt Architektur Macht Aussage über Macht Aussage über Metriken Hilfsmittel Software-Analyse 3
Einleitung: Konzept und Motivation Ziel: Architektur und Qualität Als Werkzeuge zur Software-Analyse darstellen Greifbar und erkennbar machen Dazu: Knappe Definitionen Muster und Eigenschaften, Beispiele Motivation: Software-Design Rechtzeitig planen Qualität sicherstellen Software-Analyse Herausfinden, was man von einem System erwarten kann 4
Gliederung - Architektur Architektur Definitionen Motivation Qualität Anforderungen Architekturstile 5 Typen Eigenschaften Beispiel Anwendung Zusammenhang Qualität/Architektur 5
Was ist eine Software-Architektur? Control- Prozess GUI Logik Datenbank Stellt das Diagramm eine Architektur dar? 6
Was ist eine Software-Architektur? Control- Prozess GUI Logik Datenbank Stellt das Diagramm eine Architektur dar? Nein, denn wichtige Fragen bleiben unbeantwortet: Was sind die Komponenten? Was sind die Verknüpfungen? Warum wurde das Diagramm so strukturiert? Wie verhält sich das System zur Laufzeit? 7
Definition Software-Architektur Die Struktur der Software-Komponenten eines Systems mit ihren nach außen sichtbaren Eigenschaften und ihren Beziehungen untereinander. [Bass] Architektur steht am Anfang des System-Designs Zum High-Level-Design gehören jedoch auch noch andere Dinge Eine Architektur legt die Struktur eines Systems fest Eine System kann jedoch mehrere Strukturen haben Eine Architektur definiert Komponenten und Beziehungen Man muss zwischen Runtime und Designtime unterscheiden 8
Motivation für Architekturen Kommunikation zwischen den Projektmitgliedern Besonders geeignet für Stakeholder-Kommunikation Relativ leicht zugänglich, da auf hoher Ebene Erste Möglichkeit, Design-Entscheidungen zu treffen Entscheidungen der Architektur betreffen den gesamten Produktzyklus Die Architektur ist der erste analysierbare Teil eines SW-Systems Wiederverwendbare Abstraktion eines Systems Vergleiche Design-Patterns 9
Gliederung - Qualität Architektur Definitionen Motivation Qualität Anforderungen Architekturstile 5 Typen Eigenschaften Beispiel Anwendung Zusammenhang Qualität/Architektur 10
Was ist Qualität? Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte Erfordernisse zu erfüllen. [ISO8402] Definition von Qualität ist sehr schwierig Alternative Definitionen: Qualität ist Kundenzufriedenheit [Datev] Qualität heißt, die Anforderungen eines Menschen zu erfüllen [Weinberg] Qualität ist die Fehlerfreiheit eines Produktes [Thraller] 11
Qualitätsanforderungen Typ Beschr. Beispiel Funktionale Anforderungen Was? Programm berechnet Produkt zweier Zahlen. nicht funktionale Anforderungen laufzeit-relevant nicht laufzeit-relevant Wie? Die Zahlen müssen je 10 hoch 10 Stellen haben Antwortzeit muss unter 5ms liegen 12
Qualitätsanforderungen Typ Beschr. Beispiel Funktionale Anforderungen Was? Programm berechnet Produkt zweier Zahlen. nicht funktionale Anforderungen laufzeit-relevant nicht laufzeit-relevant Wie? Die Zahlen müssen je 10 hoch 10 Stellen haben Antwortzeit muss unter 5ms liegen Wichtiger Unterschied: bei der Architektur-Auswahl beachten Beispiel: Modularität der Architektur!= Modularität zur Laufzeit 13
Performanz (Performance) Zeit, die vergeht, bis auf ein Ereignis reagiert wird Verarbeitungsschritte pro Zeiteinheit Abhängig von: Kommunikation (dauert meist länger als Berechnung) Effiziente Algorithmen Kann auf Architektur-Ebene gemessen werden Simulation auf Grundlage der Architektur möglich Früher war Performanz die treibende Anforderung Heute rücken wegen Overprovisioning andere Anforderungen in den Vordergrund laufzeit-relevant architekturabhängig 14
Sicherheit (Security) Fähigkeit, unautorisiertem Zugriff zu widerstehen Fähigkeit, denial-of-service Angriffen zu widerstehen Abhängig von: Authorisierungsserver Netzwerk-Monitor Firewall Trusted Kernel Folgerung: Es werden spezielle Komponenten und Schnittstellen benötigt laufzeit-relevant architekturabhängig 15
Verfügbarkeit (Availability) mean time to failure mean time to failure + mean time to repair Abhängig von: Fehlertoleranz des Systems / der Architektur Error-Handling Verdopplung kritischer Komponenten und Schnittstellen Wartbarkeit und Testbarkeit Maß für die Zeit, in der ein System wie vorgesehen läuft Eng verknüpft mit Zuverlässigkeit laufzeit-relevant architekturabhängig 16
Bedienbarkeit (Usability) Lernbarkeit und Einprägsamkeit Effizienz, Fehlertoleranz und Zufriedenheit Abhängig von: Genaue Beobachtung der Benutzer Abbildung des Denk-Modells der Nutzer in Software-Modell Standards Größtenteils nicht durch Architektur beeinflussbar Jedoch: Schnittstellen beispielsweise zur GUI beeinflussen die Bedienbarkeit laufzeit-relevant nicht architekturabhängig 17
Modfizierbarkeit (Modifiability) Die Fähigkeit, schnell und günstig Änderungen durchzuführen Lokalität von Änderungen Abhängig von: Wie begrenzt sind Änderungen (Lokalität)? Erweiterung der Funktionalität Löschen oder Vereinfachen Anpassung/Portierung auf neue Systeme Umstrukturierungen Lose Kopplung von Komponenten Faustregel: Lokale Änderungen sind billiger als globale Spezialfall: Wiederverwendbarkeit nicht laufzeit-relevant architekturabhängig 18
Portierbarkeit (Portability) Fähigkeit eines Systems, unter verschiedenen Umgebungen zu laufen Abhängig von: Kapselung von plattform-spezifischen Eigenschaften Portability-Layer Verschiedene Umgebungen sind: Hardware Software Kombination von beidem Portability-Layer ist nur auf Architektur-Ebene sichtbar nicht laufzeit-relevant architekturabhängig 19
Integrierbarkeit (Integrability) Die Fähigkeit von Einzelkomponenten zum Zusammenspiel Abhängig von: Komplexität der Komponenten nach aussen Interaktions-Mechanismen Protokolle Klare Aufteilung der Aufgaben Interoperabilität: Zusammenspiel von Systemen nicht laufzeit-relevant architekturabhängig 20
Testbarkeit (Testability) Fähigkeit eines Systems, seine Fehler aufzuzeigen Abhängig von: Kontrollieren des Zustands jeder Komponente Überwachen der Ausgaben jeder Komponente Genauer: Das System hat mindestens einen Fehler Das System ist gut testbar, wenn dieser Fehler beim nächsten Test auch auftritt Also schnell gefunden werden kann nicht laufzeit-relevant architekturabhängig 21
Übersicht: Qualitätsanforderungen laufzeit-relevant Performanz ++ Kommunikation, Parallelisierung Sicherheit o Spezielle Sicherheits-Komponenten Verfügbarkeit Benutzbarkeit ++ Fehlertoleranz, Redundanz - - nicht laufzeit-relevant Modifizierbarkeit Portierbarkeit Integrierbarkeit Testbarkeit ++ Modularisierung, Kapselung ++ Portability-Layer + Einfache Schnitstellen, Protokolle + Kontrolle, Überwachung (einzelner Komponenten) 22
Kompromisse Sicherheit Gummiband Bedienbarkeit Qualitätsanforderungen beeinflussen sich gegenseitig Es können nicht alle Anforderungen zu 100% erfüllt werden Qualitäten müssen priorisiert werden I will contend that conceptual integrity is the most important consideration in system design. [Fred Brooks] 23
Gliederung - Architekturstile Architektur Definitionen Motivation Qualität Anforderungen Architekturstile 5 Typen Eigenschaften Beispiel Anwendung Zusammenhang Qualität/Architektur 24
Architekturstile Schlüssel-Komponenten und Regeln, um diese zu verbinden: Komponenten-Typen z.b. Prozess, Speicher, Prozedur Topologische Anordnung um die Laufzeit-Zusammenhänge zu verdeutlichen Semantische Beschränkungen z.b. Ein Speicher kann seinen Inhalt nicht selber ändern Verbinder, die Kommunikation, Koordination und Kooperation zwischen Komponenten ermöglichen z.b. Routinen-Aufruf, RPC, Sockets Stil als abstrakte Klasse, von Architektur implementiert 25
Notation Komponenten Prozess Komponente oder Objekt Passiver Speicher Aktiver Speicher Verbinder Kontroll-Fluss Daten-Fluss 26
Architekturstile: Übersicht Independent Components Communicating Processes Implicit Invocation Event Systems Explicit Invocation Data Flow Data-Centered Batch Sequential Pipes and Filters Repository Blackboard Virtual Machine Call and Return Interpreter Rule-Based System Programm and Subroutine Object Oriented Layered 27
Data-Centered -Architektur Zugriff und Veränderung eines gemeinsamen Daten-Speichers Bietet: Integrierbarkeit der Daten Typen: Repository: Passiver Daten-Speicher (Bsp.: Datei) Blackboard: Aktiver Daten-Speicher (Bsp.: Datenbank) Client Client Daten-Speicher Client Client 28
Data-Flow -Architektur Eine Abfolge von Operationen auf Eingangs-Daten anwenden Bietet: Modifizierbarkeit Wiederverwendbarkeit Typen: Batch-Sequential: Komponenten sind eigenständige Programme Pipes and Filters: Ein System, verarbeitet Daten als Stream Syntax-Check Parsen Sortieren 29
Virtual Machine -Architektur Erschaffung einer Abstraktions-Ebene durch Simulation Bietet: Portierbarkeit Typen: Interpreter Rule-Based Eingaben Programm- Zustand interpretiertes Programm Ausgaben Interpreter interner Zustand 30
Call and Return -Architektur(1) Aufteilen eines Programms in kleinere Einzelteile Bietet: Modifizierbarkeit Skalierbarkeit Wiederverwendbarkeit (Portierbarkeit) Typen: Main Program and Subroutine: Hierarchische Aufteilung RPC: Wie oben nur im Netzwerk verteilt Object-Oriented: Aufteilung in Objekte Layered: Aufeinander aufbauende Schichten 31
Call and Return -Architektur(2) Main Sub1 Sub2 Main and Subroutine Objekt Object-Oriented Objekt User Interface Layered Spezielle Funktionen Objekt Objekt Allgemeine Funktionen 32
Independent Component -Architektur Kommunizierende Objekte, die sich nicht direkt kontrollieren Bietet: Modifizierbarkeit Wiederverwendbarkeit Skalierbarkeit und Performanz Typen: Event Systems: Observer-Prinzip Communicating Processes: Bsp.: Client-Server Client Server Client Client 33
Heterogene Architekturen Lokal heterogen Scheint zur Laufzeit eine einheitliche Architektur zu haben Besteht jedoch aus mehreren Architekturen Bsp.: Main and Subroutines mit gemeinsamem Speicher Hierarchisch heterogen Architekturen sind ineinander verschachtelt Unter-Komponenten sind anders aufgebaut, als Gesamt-System Heutzutage häufig Kombination von Objekt-Orientierter Tier -Architektur mit Layered -Architektur. 34
Architekturstile: Zusammenfassung Independent Components Performanz Sicherheit Data-Flow Verfügbarkeit Benutzbarkeit Data-Centered Modifizierbarkeit Wiederverwendbark. Virtual Machine Portierbarkeit Integrierbarkeit Call and Return Testbarkeit 35
Gliederung - Beispiel Architektur Definitionen Motivation Qualität Anforderungen Architekturstile 5 Typen Eigenschaften Beispiel Anwendung Zusammenhang Qualität/Architektur 36
Beispiel: KWIC (Keyword in Context) Liest Strings ein Vertauscht die Wörter der Strings zyklisch miteinander Sortiert die resultierenden Strings alphabetisch Ich wünsche ein frohes Fest und einen guten Rutsch 6) Ich wünsche ein frohes Fest 3) Fest Ich wünsche ein frohes 4) frohes Fest Ich wünsche ein 1) ein frohes Fest Ich wünsche 9) wünsche ein frohes Fest Ich Sinn: Schnell durchsuchbaren Index erzeugen 8) und einen guten Rutsch 7) Rutsch und einen guten 5) guten Rutsch und einen 2) einen guten Rutsch und 37
Beispiel: Data Centered -Architektur Kontrolle Eingabe Vertauschen Sortieren Ausgabe Zeichen Index sortierter Index 38
Beispiel: Call and Return (OO) -Architektur Kontrolle Eingabe Ausgabe Zeichen Vertauschen Sortieren Zeichen Index sortierter Index 39
Beispiel: Pipe and Filter -Architektur Eingabe Vertauschte Zeilen Sortierte Ausgabe Vertauschen Sortieren 40
Beispiel: Vergleich Data Centered Call and Return Pipe and Filter Ändern des Datentyps -- + - Ändern der Funktionalität - + ++ Performanz ++ - o Wiederverwendbarkeit - ++ + There is no silver bullet. [Fred Brooks] 41
Literaturempfehlung Software Architecture in Practice 2 nd edition L.Bass, P.Clements, R. Kazman 512 Seiten Addison-Wesley Professional 2003 ca. 50,- eur 42
Zusammenfassung Independent Components Data-Flow Data-Centered Call and Return Virtual Machine C. Processes Event System Batch Pipe Repository Blackboard Main and Sub Object Oriented Layered Performanz Sicherheit Verfügbarkeit Benutzbarkeit Modifizierbarkeit Wiederverwendbark. Portierbarkeit Integrierbarkeit Testbarkeit 43
Anhang Anhang 44
Einleitung: Motivation Mit dem Auto unterwegs in einer fremden Stadt Unter Zeitdruck Lesen einer Karte oder Passanten fragen kostet Zeit, die man nicht hat Man fährt nach Gefühl drauf los...und kommt erst recht zu spät We don't have the time to be efficient. 45
Weitere Begriffe Referenz Modell Architektur Stil Referenz Architektur Software Architektur Architektur Stil Einer Architektur auferlegte Zwänge Beschreibung von Typen und Mustern Beispiel: Client-Server Referenz Modell Teilfunktionalität eines Systems inklusive Datenfluss Beispiel: Standard Komponenten einer Datenbank-Anwendung Referenz Architektur Projektion eines Referenz Modells auf ein Software-Sytem Beispiel: ilam-system, SE-Anmelde-System 46
Wiederverwendbarkeit (Reusability) Struktur oder Komponenten eines Systems können später wiederverwendet werden Abhängig von: Lose Kopplung zwischen Komponenten Um eine Komponente in einem neuen System zu nutzen muss man Die dazu erforderlichen Komponenten mitnehmen Äquivalente bereitstellen Spezialfall von Modifizierbarkeit architekturabhängig 47
Anforderungen an die Architektur I will contend that conceptual integrity is the most important consideration in system design. [Fred Brooks] Architektur selbst kann gewissen Anforderungen erfüllen: Konzeptuelle Integrität (conceptual integrity) Richtigkeit und Vollständigkeit (correctnes and completeness) Umsetzbarkeit (buildability) Lieber auf einzelne Qualitäts-Anforderungen verzichten, als auf ein durchgängiges und einheitliches Architektur-Konzept 48
Motivation für Architekturen (2) Was leistet eine Architektur? Legt Struktur der Implementation fest Damit auch teilweise die Organisation des Projektes Erlaubt Optimierung auf bestimmte Qualitäten hin Erleichtert Änderungen (einzelner Komponenten) Ermöglicht den Aufbau ganzer Produkt-Linien Erleichtert das Verwenden von vorgefertigten Komponenten Ein wichtiger Teil der Dokumentation 49