Softwareproduktlinien Teil 11: Nicht-funktionale Eigenschaften. Norbert Siegmund (Universität Magdeburg)

Transkript

1 Softwareproduktlinien Teil 11: Nicht-funktionale Eigenschaften Norbert Siegmund (Universität Magdeburg) 1

2 Einführung Bisher nicht betrachtet: Konfiguration von Produktlinien Nicht-funktionale Eigenschaften Vorhersage und Messung von Produkten 2

3 Agenda Einführung Konfiguration und nicht-funktionaler Eigenschaften Lösungsansätze zum Messen und Vorhersagen Erfahrungsberichte Ausblick 3

4 4 Konfiguration von Softwareproduktlinien

5 Wiederholung: Produktlinien Wiederverwendbare Artefakte Autovarianten Konfiguration basierend auf Anforderungen Variantengenerierung 5

6 Wiederholung: Softwareproduktlinien Wiederverwendbare Artefakte (Code, Doku, etc.) Varianten Konfiguration basierend auf Anforderungen Variantengenerierung 6

7 Konfiguration mit Featuremodellen Funktionale Anforderungen Verschlüsselung Kompression Datenanalyse Reporting Database Management System optional mandatory alternative or Cache Size Encryption Transaction Compression Indexes Reporting Page Size 8MB 32MB 128MB Logging Commit Protocols R-tree B-tree Hash 2K 4K 8K 16K 7 Partielle Featureauswahl

8 Nicht-funktionale Anforderungen Nicht nur Funktionalität ist wichtig! Performance Speicherverbrauch Footprint 8

9 Nicht-funktionale Eigenschaften: Definition(en) Auch bekannt als Qualitätseigenschaften Über 25 Definitionen (siehe [6]) Allgemein: Jedwede Eigenschaft eines Produktes, welche nicht zur Funktionalität zugeordnet werden kann, ist eine nichtfunktionale Eigenschaft. Verschiedene Modelle beschreiben Beziehungen zwischen nicht-funktionalen Eigenschaften 9

10 McCall s Qualitätsmodell I [7] Modellierung von Qualitätseigenschaften und faktoren, um Kommunikation zwischen Entwicklern und Benutzern zu vereinfachen Hierarchisches Modell mit: 11 Faktoren (spezifizieren das Produkt; externe Sicht des Nutzers) 23 Qualitätskriterien (zum Entwickeln; interne Sicht des Entwicklers) Metriken (zum Kontrollieren und Evaluieren) 10

11 McCall s Qualitätsmodell II Externe Sicht Interne Sicht 11

12 Boehm s Modell der nicht-funktionalen Eigenschaften [1] 12 device-independence portability self-containedness accuracy completeness reliability robustness/integrity General utility consistency efficiency As-is utility accountability usability device efficiency accessibility testability communicativeness Maintainability self-descriptiveness understandability structuredness conciseness modifiability legibility augmentability

13 ISO Standard 9126 Quelle: Wikipedia 13

14 Kategorisierung Quantitativ (Leistungsanforderungen) Antwortzeiten (Performance), Lastgrenzen und Durchsatz Energie- und Speicherverbrauch Messbare Eigenschaften (metrische Skala) Evaluierbar Qualitativ (Qualitätsanforderungen) Erweiterbarkeit Fehlerfreiheit Robustheit Sicherheit 14 Nur indirekt messbar (keine geeignete Metrik vorhanden)

15 Wie konfiguriert man nicht-funktionale Eigenschaften? Nicht-funktionale Anforderungen Energieverbrauch Hauptspeicherverbrauch Performance Footprint Maximiere Performance, aber halte Footprint unter 450 KB optional Database Management System mandatory alternative or Cache Size Encryption Transaction Compression Indexes Reporting Page Size 8MB 32MB 128MB Logging Commit Protocols R-tree B-tree Hash 2K 4K 8K 16K 15

16 Motivierende Fragen mit praktischer Relevanz Wie groß ist der Footprint einer Variante für eine gegebene Featureauswahl? Database Management System 425 KB Cache Size Encryption Transaction Compression Indexes Reporting Page Size 8MB 32MB 128MB Logging Commit Protocols R-tree B-tree Hash 2K 4K 8K 16K Was ist die beste Featureauswahl, um den Hauptspeicherverbrauch zu minimieren? Min( ) Cache Size Encryption Transaction Database Management System Compression Indexes Reporting Page Size Welches sind die Performance-kritischsten Features? Database Management System 8MB 32MB 128MB Logging Commit Protocols R-tree B-tree Hash 2K 4K 8K 16K Cache Size Encryption Transaction Compression Indexes Reporting Page Size 16 8MB 32MB 128MB Logging Commit Protocols R-tree B-tree Hash 2K 4K 8K 16K

17 Einordnung Domain Eng. Feature-Modell Wiederverwendbare Implementierungsartefakte Application Eng. Feature-Auswahl Generator Fertiges Program 17

18 18 Messen von nicht-funktionalen Eigenschaften

19 Ausflug: Messtheorie Stevens definiert verschiedene Levels des Messens [4] Beispiele: 19 Geschlecht Schulnoten Zeitskala (Datum) Alter Quelle: Wikipedia

20 Klassifizierung von nicht-funktionalen Eigenschaften für Produktlinien Nicht-messbare Eigenschaften entsprechen: Qualitative Eigenschaften Eigenschaften für die wir keine sinnvolle Metrik finden (Wartbarkeit?) Messbar pro Feature Eigenschaften existieren für einzelne Feature Quellcode Eigenschaften, binäre Größe Messbar pro Variante Eigenschaften existieren nur im fertigen Programm Performance, Speicherverbrauch, etc. 20

21 Methoden des Messens für Produktlinien Auf welche Art und Weise können wir nicht-funktionale Eigenschaften von Produkten einer Produktlinie messen? Artefaktbasiert Familienbasiert Produktbasiert 21

22 Ableitung: Messen von Produktlinien I Artefaktbasiert Features werden direkt und in Isolation von anderen Features gemessen Linearer Aufwand bzgl. Anzahl der Features Robust gegenüber Änderungen der Produktlinie Nachteile: Nicht alle Eigenschaften messbar (Performance?) Erfordert bestimmte Implementierungstechniken (#ifdef?) Keine black-box Programme, da Code benötigt wird Keine Featureinteraktionen (geringe Genauigkeit) Erfordert künstliche Messumgebung Aufwand Genauigkeit Anwendbarkeit Generalität Umgebung

23 Ableitung: Messen von Produktlinien II Familienbasiert Alle Features und deren Kombinationen werden auf einmal gemessen Mit Hilfe des Featuremodells wird der Einfluss einzelner Features danach abgeleitet Aufwand: O(1) Nachteile (ähnlich wie zuvor): Nicht alle Eigenschaften messbar, künstliche Umgebung Ungenau bei Featureinteraktionen, spezielle Implementierungstechniken von nöten 23 Aufwand Genauigkeit Anwendbarkeit Generalität Umgebung

24 Ableitung: Messen von Produktlinien III Produktbasiert Einzelne Varianten wird gemessen Jede Eigenschaft kann mit Standardprogrammen gemessen werden Anwendbar für black-box Programme Unabhängig von der Implementierungstechnik Messen des Einflusses von Featureinteraktionen möglich Nachteil: 24 Sehr hoher Aufwand O(2 n ) Aufwand Genauigkeit Anwendbarkeit Generalität Umgebung

25 Messen der Performance von SQLite Angenommen wir messen alle Varianten von SQLite: 2 85 Variants 5 per Messung (Kompilieren + Benchmark) 2 85 * 5min = 368,013,948,132,307,206,912 Jahre Jetzt 1.37 * Jahre Logarithmische Zeitlinie Big bang Geburt der Erde 9 * 10 9 Jahre Messung beendet 3.6 * Jahre 25

26 26 Vorhersage von nicht-funktionalen Eigenschaften

27 Vorhersageverfahren Regression Neuronale Netze CART Bayse Nets MARS M5 Cubist Principal Component Analysis Evolutionäre Algorithmen Arbeitsgruppe Computational Intelligence 27

28 Heuristiken Input: Partielle Featureauswahl Vorhersage Resultat Page Size Cache Size 4k Performance: 20s PageSize 4k B-tree Ziel: max (Performance) Idee: Addiere den Einfluss ausgewählter Features Page Size Cache Size 1k 4k = 80s = 30s = 10s 28 = 120s

29 Bestimmen des Einflusses einzelner Features Aber wie soll das gehen? DBMS Core Compression Encryption Transactions Π ( ) = 100s Π (, ) = 120s Π ( ) = 100s Π ( ) = 100s Π (, ) = 130s Π (, ) = 110s Δ ( ) = 20s Δ ( ) = 30s Δ ( ) = 10s Π (,,, ) = Δ ( ) + Δ ( ) + Δ ( ) + Δ ( ) = 160s 29

30 30 Erfahrungen

31 Lösung 1: Feature-Wise Measurement Evaluierung für Footprint (Binärgröße), Hauptspeicherverbrauch, und Performance 31

32 Footprint Material: Produktlinie Domäne Herkunft Sprache Features Varianten LOC Prevayler Database Industrial Java ZipMe Compression Academic Java PKJab Messenger Academic Java SensorNet Simulation Academic C Violet UML editor Academic Java 100 ca Berkeley DB Database Industrial C SQLite Database Industrial C 85 ca Linux kernel Operating system Industrial C 25 ca. 3 *

33 Hauptspeicherverbrauch Material: Produktlinie Domäne Technik Sprache Features Varianten LOC Curl Data trabsfer Parameter C LLVM Compiler Parameter C X264 Video encoding Parameter C Wget Data transfer Parameter C Berkeley DB Database Compilation C SQLite Database Compilation C RAR Compression Parameter C N/A 33

34 Experimental Setup and Validation Experiment mit zwei Phasen Lernphase: Messe zwei Varianten pro Feature und berechne Delta, um ein Vorhersagemodell zu erstellen Validationsphase: Messe alle Varianten und vergleiche vorhergehesene mit gemessene Eigenschaftsize Fehlerrate: 34

35 Ergebnisse für Footprint Mittlere Fehlerrate von 5.5% ohne Violet Mit Violet: 21.3% # von Messungen SQLite: 85 vs Linux : 25 vs. 3*10 7 Warum diese Fehlerrate? 186% fault rate Prevayler 35

36 Main-Memory Consumption Fehlerrate: 13.6 % Beobachtungen: Fehlerate ändert sich in Abhängigkeit der Eigenschaften und verwendeten Programme (ähnliche Ergebnisse für Performance) 36

37 Analyse der Ergebnisse: Featureinteraktionen Zwei Features interagieren wenn: Ihre gleichzeitige Präsenz in einem Programm unvorhergesehenes Verhalten verursacht Erwartet Gemessen Π (,, ) = Δ( ) + Δ ( ) + Δ ( ) = 100s + 20s + 30s = 150s 37 = 140s* Δ( # ) = -10s //delta zw. vorhergesagte // und gemessene Performance Feature Interaktion: # da verschlüsselte Daten vorher gepackt wurden

38 Lösung 2: Interaction-Wise and Pair-Wise Measurement Evaluierung für Footprint (Binärgröße) und Hauptspeicherverbrauch 38

39 Weiter entwickelte Ansätze Interaction-wise measurement: Manuell Interaktionen definieren Benötigt Domänenwissen Mapping zwischen Features und Implementierungseinheiten Statische Source-code Analyse Pair-wise measurement: Wir nehmen an, dass zwischen jedem Paar von Features eine Interaktion besteht Bestimmen des Einflusses dieser Interaktionen 39

40 Pair-wise Measurement: Footprint Mittlere Fehlerrate von 0.2% ohne Violet Veringerung von 4.3 % # Messungen: SQLite: 3306 vs Linux : 326 vs. 3*10 7 Teilweise Verbesserung, aber nicht immer 722% Fehlerrate 40

41 Pair-wise Measurement: Hauptspeicherverbrauch Fehlerrate von 11 % (0.9 % ohne LLVM und Wget) Verringerung von 2.6 % im Vergleich zu feature-wise measurement 41

42 Interaction-Wise Measurement: Footprint Source-code Analyse zeigte Featureinteraktionen höherer Ordnung in Violet # Messungen: SQLite: 146 vs Linux : 207 vs. 3*10 7 Mittlere Fehlerrate von 0.2% mit Violet 42

43 Analyse der Ergebnisse Vorhersagen müssen Featureinteraktionen berücksichtigen Domänenwissen wird benötigt Bei paarweisen Interaktionen Schlecht skalierbar: O(n 2 ) für n Features Ungenau wenn Interaktionen höherer Ordnung existieren Weitere Forschungsfragen: Wie sieht die Verteilung von Featureinteraktionen aus? Interagieren alle Features oder nur wenige? Welche Ordnung von Interaktionen sind am Häufigsten? Sind Muster bzgl. der Interaktionen erkennbar? 43

44 Verteilung von Featureinteraktionen? 44 Einsicht 1: Wenige Features interagieren mit vielen (hot-spots) and viele Features interagieren mit nur wenigen.

45 Interagieren alle Features oder nur wenige? Einsicht 3: Die meisten Interaktionen sind paarweise Interaktionen! 45 Einsicht 2: Viele Features interagieren nicht!

46 Muster von Featureinteraktionen? F1#F2#F3#F4 F1#F2#F4 F1 F1#F2 F2 F3#F1#F2 Einsicht 4: Es gibt Muster wie F3#F1 F4#F2 Interaktionen auf Res höhere Ordnungen propagieren! F3#F4#F2 F3 F3#F4 F4 F1#F3#F4 46

47 Was wollen wir erreichen? Können wir automatisiert Featureinteraktionen finden ohne Domänenwissen für black box Programme unabhängig von Programmiersprache, Konfigurationstechnik, und Domäne, um die Vorhersagegenauigkeit zu verbessern? 47

48 Was haben wir? Einsichten: Nicht alle Features interagieren, Die meisten Interaktionen sind paarweise, Viele Features interagieren mit nur wenigen Features und wenige Features mit vielen, Es gibt ein Muster, wie Interaktionen sich auf höhere Ordnungen auswirken. Modell, welches beschreibt, wann welche Interaktionen in einem Produkt vorkommen [5] 48

49 Kompositionsmodell nach Batory [5] Generiere Programm P mit Features call forwarding (cf) und call waiting (cw) P = cf cw Features interagieren immer (aber nicht immer beobachtbar) Wartet der Anrufer? Wird er weitergeleitet? Tritt ein Fehler auf? Also: wir generieren ein Programm mit den Verhalten von Features und deren Interaktionen Skalierung: P(cf cw) = cf cw cf#cw P(a b c) = a b c a#b a#c b#c a#b#c 49

50 Mapping von Komposition zu Eigenschaften Die nicht-funktionale Eigenschaft Π (z.b., Performance) einer Featurekomposition ist die Aggregation (z.b., Summe) der Eigenschaften ihrer Features: Π (P) = Π(cf cw) = Π(cf cw cf#cw) = Π(cf) Π( ) Π(cw ) Π( ) Π(cf#cw) = Π(cf) + Π(cw ) + Π(cf#cw) Die Homomorphismusrelation Π( ) definiert die Aggregationfunktion für eine bestimmte Eigenschaft 50

51 Schrittweiser Ansatz (basierend auf Einsicht 2) Schritt 1. Finde interagierende Features Reduziert Anzahl von Kombinationen, die auf Interaktionen getestet werden müssen Benötigt oft nur n+1 zusätzliche Messungen DBMS Core Compression Encryption Transactions Diagnosis Index Logging < Schritt 2. Finde Kombinationen von interagierenden Features, die tatsächlich Featureinteraktionen auslösen Basierend auf unseren Einsichten 51

52 Schritt 1. Finde interagierende Features I Was beschreibt ein Delta genau? Π ( ) Π (, ) Δ ( ) = Π ( ) + Π ( # ) Π (, ) Π (,, ) Δ ( ) = Π ( ) + Π ( # ) + Π ( # ) + Π ( # # ) 2 Terme 4 Terme Π (,, ) Π (,,, ) Δ ( ) = Π ( ) + Π ( # ) + Π ( # ) + Π ( # # ) + Π ( # ) + Π ( # # ) + Π ( # # ) + Π ( # # # ) 8 Terme 52

53 Schritt1: Finde interagierende Features II Idee: Vergleiche die Deltas, die sich am wahrscheinlichsten unterscheiden Minimales Produkt Maximales Produkt Π ( ) = 100s Π (, ) = 120s Δ ( ) = 20s Π (,,,,, ) = 170s Π (,,,,,, ) = 180s Wenn minimal Δ maximal Δ dann interagierendes Feature Minimal Maximal Δ ( ) = Π ( ) + Π ( # ) Δ ( ) = Π ( ) + Π ( # ) + Π ( # ) + Π ( # ) + Π ( # ) + Π ( # ) zusätzliche Terme! 53 Δ ( ) = 10s

54 Schritt 2. Finde tatsächliche Featureinteraktionen Welche Kombinationen von interagierendes Features bewirken Interaktioen? Ansatz: Messe zusätzliche Konfigurationen, um Interaktionen zu finden Benutze Heuristiken (abgeleitet aus den Einsichten), um diese zusätzlichen Konfigurationen zu bestimmen 54

55 Schritt 2. Pair-wise (PW) and Higher-Order Interactions (HO) Heuristik 1: Messe paarweise Kombinationen zuerst Basierend auf Einsicht 3 Heuristik 2: Wenn zwei der folgenden paarweisen Kombinationen {a#b, b#c, a#c} interagieren, messe die 2.Ordnungsinteraktion {a#b#c} Basierend auf Einsicht 4 Heuristik 3: Messe höhere Ordnungsinteraktionen für hotspot Features Basierend auf 1 55

56 Lösung 3: Automatisierte Detektion von Featureinteraktionen Evaluierung für Performance 56

57 Evaluation Produktlinie Domäne Herkunft Sprache Techn. Features Varianten LOC Berkeley DB Database Industrial C C ,811 Berkeley DB Database Industrial Java C ,596 Apache Web Server Industrial C CF ,277 SQLite Database Industrial C C 39 3,932, ,625 LLVM Compiler Industrial C++ CLP ,549 x264 Video Industrial C CLP ,743 C: Encoder compilation; CF: configuration files; CLP: command-line parameters Setup: Ausführung eines Standardbenchmarks Heuristiken aufeinander aufbauend anwenden 57

58 Tool Support: SPL Conqueror Messen, konfigurieren, und optimieren von nicht-funktionalen Eigenschaften ( 58

59 Resultate Feature-Wise Fehlerrate Mean Median 20.3 % % + Pair-Wise Heuristic Mittlere Fehlerrate von 4.6% ist unter der Messungenauigkeit 9.1 % 4.32 % + Higher-Order Heuristic 6.3 % 3.06 % + Hot-Spot Heuristic 4.6 % 2.36 % 59

60 Zusammenfassung des Ansatzes Zwei Tage Messungen mit einer Genauigkeit von 93% Jetzt 1.37 * Jahre Zeitachse Big bang Geburt der Erde: 9 * 10 9 Jahre Messung beendet 3.6 * Jahre 61

61 Lösung 4.0: Future Work (Themen für Bachelor- und Masterarbeiten) Workload-aware prediction Combination with related prediction approaches White-box analysis and prediction Optimization of energy consumption 62

62 Einbeziehung des Workloads in die Vorhersage Δ(Feature) = 20 s Δ(Feature, Workload) = f(workload) In cooperation with: 63

63 Messung und Optimierung des Energieverbrauchs Bibliotheken mit Features implementieren wiederkehrende Funktionalität energieeffizient Einweben von Code mit FOP/AOP Weaving energy optimizing code into a program (e.g., automatic device management based on feature usage) 64

64 Energy Feature Library Idea: Automatically applying energy-saving techniques to programs Bundling energy features (concrete optimization techniques) in a library Alternative energy-saving algorithms OS-dependent energy management techniques for different hardware components 65 Applying energy features with a mapping to a target program (or program s functionality) Replacing algorithms in the target program with energy-saving alternatives Encapsulating hardware-utilizing functionality with energy management

65 Energy Feature Library Idea: Automatically applying energy-saving techniques to programs.. Goals: Reusing energy optimizations in different programs Application of energy features does not require expert knowledge Reduced implementation effort by means of automatic integration of energy features 66

66 Feature Model of the Energy Feature Library A configuration represents single energy-saving technique Selecting OS and Device features results in an optimization utilizing the OS energy management API Select a feature of Algorithms Collection results the replacement of program functionality 67

67 Mapping Features to Application Functionality Where to apply the energy-saving functions? Mapping application features to energy features Encapsulating the application functionality with energymanagement mechanisms Replacing an application feature with energy-efficient alternative 68

68 Manual Layered Composition I Using feature-oriented composition process Integrate the energy functionality with feature modules Features: Class Database Class QueryExecution Class EnergySplClass Base put(..) performquery(..) Data Sort sort(..) Application features Distributed send(..) Win_WLAN InsertionSort send(..) Method calls sort(..) activatewlan(..) deactivatewlan(..) Energy features 69 No super call

69 Manual Layered Composition II Provide a skeleton for each generated energy feature module Parameters define pointcut in the application 70

70 Automated Layered Composition Using aspectual mixing layers to Use aspects for pointcut definition Feature modules for implementation of energy features 71

71 Energy Manager A meta-program (energy manager) verifies at runtime whether to execute the code of an energy feature Verification uses the defined mappings and is executed at each entry point of a feature s code Integrate OnExecute(FEATURE_NAME) method calls at the beginning of each public method of each feature Method creates object of class FeatureExec Constructor executes the energy manager Using a destructor or a timer to automatically call deactivation of hardware components 72

72 Zusammenfassung Nicht-funktionale Eigenschaften spielen eine große Rolle bei der Auswahl eines Produktes aus einer Produktlinie Qualitative und quantitative Eigenschaften Problem des Messaufwandes für quantitative Eigenschaften Ansatz: Vorhersage der Eigenschaften durch Messen von nur wenigen Konfigurationen Konfigurationen werden mittels Heuristiken bestimmt Ziel ist es Featureinterkationen zu finden und deren Einfluss auf nicht-funktionale Eigenschaften zu bestimmen 73

73 Ausblick Variabilitätsgewahre Analysen (Thomas Thüm) Kompositionssicherheit Typsicherheit Spezifikation und Verifikation Big Picture Produktlinien Maßschneiderung von Datenhaltungssoftware??Prüfungsvorbereitung?? Noch unsicher 74

74 Literatur [1] Boehm et al., Characteristics of Software Quality. Elsevier, [2a] Siegmund et al. Scalable Prediction of Non-functional Properties in Software Product Lines. In Proceedings of International Software Product Lines Conference (SPLC), pages IEEE, [2b] Siegmund et al. Predicting Performance via Automated Feature-Interaction Detection. In Proceedings of International Conference on Software Engineering (ICSE), [3] Patrik Berander et al, Software quality attributes and trade-offs, Blekinge Institute of Technology, 2005 ( ding-materials/p10/software_quality_attributes.pdf) [4] Stanley S. Stevens. On the theory of scales of measurement. Sciences, 103(2684): , [5] Batory et al., Feature interactions, products, and composition. In Proceedings of the International Conference on Generative Programming (GPCE), pages ACM, [6] Martin Glinz. On non-functional requirements. In International Conference on Requirements Engineering, pages IEEE, [7] McCall et al., Factors in software quality. Volume I. Concepts and definitions of software quality. Technical Report, General Electric Co Sunnyvale California,