Erweiterte Programmierkonzepte für Maßgeschneiderteres Datenmanagement (EPMD) Teil 1: Einführung und Überblick

Transkript

1 Erweiterte Programmierkonzepte für Maßgeschneiderteres Datenmanagement (EPMD) Teil 1: Einführung und Überblick Christian Kästner (Carnegie Mellon University) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg) 1 Dozent: Norbert Siegmund Übungsleiter: Thomas Thüm

2 Agenda Formales, Organisatorisches Ziel der Vorlesung Kurzeinführung in das Themengebiet 2

3 3 Formales

4 Erwartete Vorkenntnisse Grundlagen der Softwaretechnik (Modularität, SVN, Entwicklungsprozess, ) Grundlagen der objektorientierten Programmierung und Modellierung (UML) Grundkenntnisse Java (oder C++) 4

5 Vorlesung Donnerstag 13:15 15:45 Uhr (G05/307) Raum wird eventuell geändert!!! Bachelor / Master / Diplom 2-stündig, 6 ECTS-Punkte Vorstellung und Diskussion der Vorlesungsinhalte Beginn mit nächster Vorlesung 5

6 Übung Montag 13:15 15:45 Uhr (G22A/210) 6 Ab dem ! Aktive Diskussion in der Übung wird erwartet Keine wöchentliche Abgabe von Übungszetteln Votierungssystem: 66% für Schein und Prüfungszulassung Anmeldung beim Übungsleiter erforderlich! Vorname, Nachname, Studiengang, Semester, Matrikelnummer und FIN-Login per Mail an Übungsleiter Deadline: (+1 für Master) Programmieraufgaben für Zuhause/Labor Projektarbeit entfällt

7 Programmieraufgaben Programmiertechniken ist Fokus der Vorlesung 5 Programmieraufgaben für Zuhause/Labor Jeweils mit Abgabetermin Java (oder C++), sowie einige neue Sprachen und Werkzeuge OOP, Parameter, Präprozessoren, Frameworks, FOP, AOP (für Master) 1. Übung entfällt Aufgrund der praktischen Aufgabe In Übung: Auswertung und Vorstellung der praktischen Aufgabe Aufgaben bauen aufeinander auf 7

8 1. Praktische Aufgabe 8

9 Prüfung und Schein Prüfungszulassung Praktische Übungsaufgaben Votierung Mündliche Prüfung 9

10 10 Ziel der Vorlesung

11 Forschungsnahe Vorlesung Relativ junges Forschungsgebiet Vermittlung aktueller Forschungsergebnisse (K)ein einzelnes Buch Verschiedene Bücher Konferenzpublikationen (meist Englisch) Aufgelistet jeweils am Ende eines Kapitels Viele Anknüpfungspunkte für eigene Forschungen z. B. Bachelor-, Master-, Diplomarbeiten, Praktika oder auch Dissertationen 11

12 Ziele Verständnis von Grenzen traditioneller Programmierparadigmen bzgl. der Entwicklung von Informationssystemen Techniken zur Wiederverwendung von Code und zur Maßschneiderung von Software -> Softwareproduktlinien Verschiedene Möglichkeiten zur Implementierung von Softwareproduktlinien Kenntnisse über moderne, erweiterte Programmierparadigmen Befähigung zur Bewertung, Auswahl und Anwendung erweiterter Programmiertechniken 12

13 13 Hintergrund

14 Industrielle Revolution 1980s Automatische Fließbänder (erster Industrieroboter 1961 bei General Motors) 1901 Fließband (Ransom Olds/Henry Ford) 1826 Austauschbare Teile (John Hall, nach 25 vergebl. Jahren) [Czarnecki & Eisenecker 2000] 14

15 Produktlinien in der Industrie 15

16 Auto-Produktlinie 16

17 Variantenvielfalt Varianten sind ein wesentlicher Hebel für das Unternehmensergebnis Franz Decker, Leiter Programm Variantenmanagement, BMW Group 17

18 PKW-Produktlinien vor 20 Jahren Auswahl beschränkte sich auf Autotyp und ggf. noch wenige Extras wie alternativer Kassettenrekorder oder Dachgepäckträger Eine Variante (Audi 80, 1.3l, 55PS) machte 40% des Umsatzes aus 18

19 PKW-Produktlinien vor wenigen Jahren mögliche Varianten eines Audi; mögliche Varianten eines BMW Kaum ein Auto verlässt das Werk identisch zu einem vorherigen Allein 100 verschiedene Bodengruppen für ein Modell, je nach Motor und Ausstattung 50 verschiedene Lenkräder (3 vs. 4 Speichen, Holz vs. ( Farben Kunststoff vs. Leder, Heizung, 19

20 Weitere Produktlinien 20

23 Massenproduktion 25

24 Und bei Software? Moderne Anwendungssoftwaresysteme sind Eier-legende Wollmilchsäue Bsp.: Windows Vista, Open Office, Oracle, SAP myerp, Adobe Photoshop, Nero Burning ROM Spezialisierte Software und Software für eingebettete Systeme wird immer wichtiger (aber Software groß & langsam) 27 Bsp.: PDA, Handy, Sensornetze, Mikrowelle, Fernseher, Wetterstation, Auto, Chipkarten, Bordcomputer, Router, Ubiquitious Computing 98% aller im Einsatz befindlichen Rechnersysteme sind eingebettete Systeme Ressourcenbeschränkung und heterogene Hardware erfordert maßgeschneiderte Lösungen Häufige Neuimplementierungen, lange Entwicklungszeiten, hohe Entwicklungskosten

25 Warum maßgeschneiderte Software? Ressourcenbeschränkte Systeme Kosten, Energie, Platz,. Individuelle Systeme versus individuelle Nutzung Ungenutzte Funktionalität als Risiko (unbekannte Fehler) Wartungs- / Kontroll- / Testaufwand wächst mit Funktionsumfang Marketing / Preisminimierung Schnellere Reaktion auf Marktveränderungen 28

26 Features in Microsoft Office 29

27 Linux-Kernel ca Zeilen Quelltext Sehr weitgehend Konfigurierbar > Konfigurationsoptionen! (x86, 64bit, ) Fast aller Quelltext ist optional 30

28 Datenbanken Ständig wachsendes Datenaufkommen Häufige Einbettung mit Ressourcenbeschränkungen 31

29 Drucker- Firmware 32

30 Spiele 33

31 Multi-Plattform Programme Unterschiedliche Auflösungen, CPUs, Eingabegeräte, Betriebssysteme, etc. 34

32 Softwareproduktlinien in der Industrie HP: Druckertreiber/Firmware Nokia: Mobiltelefon-Software, Browser Phillips: High-End TVs, Medizintechnik, TomTom: eingebettete Navigationssysteme Cummins: Dieselmotoren-Steuerungssoftware LG: Aufzugsteuerungssoftware Ericsson: Telecommunication switches General Motors: Powertrains Viele weitere: Gasturbinen, train control, ship control, frequency converter, internet payment gateway, helicopter avionics software, 35

33 Ziel der Vorlesung Techniken für die Entwicklung maßgeschneiderter Software, die genau die benötigte Funktionalität enthält Varianten für verschiedene Anwendungsfälle Neue Varianten können leicht hinzugefügt werden; schnelle Entwicklung; Wiederverwendung bewährter Implementierungen Kundenindividuelle Fertigung; Spezialisierung Anpassung an verfügbare Ressourcen Softwareproduktlinien (SPL): Konfiguration durch Auswahl von Features (deutsch: Merkmale) 36

34 Schätzung Circa 80% aller Softwaresysteme sind Softwareproduktlinien bzw. können von Softwareproduktlinientechnologie profitieren. 37

35 38 Maßgeschneidertes Datenmanagement

36 Maßgeschneiderte Datenhaltung Allgemeine / kommerzielle DBMS Oracle, IBM DB2, SQL Server, Obermenge aller denkbaren, kommerziell einsetzbaren Funktionalität Individuelle / spezialisierte Datenhaltungs-Software Selbst gestrickt : teuer, schwer wartbar,.. Maßgeschneiderte Software für Datenhaltung Variantenfertigung, DBMS-Produkt-Familie Gibt es noch nicht! 39

37 Kommerzielle DBMS Eierlegende Wollmilchsau Oracle, IBM DB2, Microsoft SQL Server, Obermenge aller denkbaren Funktionalität Oracle Database 11g Real Application Testing Advanced Compression Total Recall Active Data Guard Real Application Clusters Management Packs Partitioning Content Database Suite Warehouse Builder OLAP Data Mining Spatial Database Vault Advanced Security, Label Security 40 In-Memory Database Cache Microsoft SQL Server 2008 Analysis Services Data Mining Hochverfügbarkeit Always On Integration Services Verwaltbarkeit Leistung und Skalierbarkeit Entwicklung Reporting Services Sicherheit Standortintelligenz

38 Allgemeine Datenbanken Vorteil: Nachteile: Große Anwendbarkeit, da Funktionalität alle denkbaren Anforderungen umfasst Fehlende Optimierung auf bestimmte Eigenschaften (z.b. Energieverbrauch kann nicht minimiert werden, da Performance und Zuverlässigkeit auch wichtig sind) Verschwendung von Ressourcen, da Funktionalität vorhanden ist, die von der jeweiligen Anwendung nicht benutzt wird 41

39 Spezialisierte Datenbanken Beispiele: Vorteile: Nachteil: Eingebettete Datenbanken (z.b. im Auto) Domänenspezifische Datenbanken (z.b. XML Datenbanken, Geo Datenbanken, usw.) Optimiert für bestimmte Eigenschaften (z.b.: Performance vs. Energieverbraucht vs. Zuverlässigkeit) Ressourceneffizient, da nur Funktionalität enthalten ist, die tatsächlich benötigt wird 42 Hoher Implementierungsaufwand bei nur geringer Anwendbarkeit

40 Dilemma Optimierung vs. Anwendbarkeit Variable Software Optimization Applicability 43

41 Wo und warum macht Maßschneiderung für Datenbanken Sinn? 44

42 Embedded Databases Eingebettete Systeme sind weit verbreitet und sollen sehr häufig Daten erfassen z.b. Sensoren im Auto, Biotopüberwachung, Gesundheitskarte, Wetterstation, RFID, Erdbebenvorhersage, Telefonanlage, Router, Handy Ständig wachsendes Datenaufkommen, immer mehr Daten sollen erfasst werden Eingebettete Systeme unterliegen starken Ressourcenbeschränkungn Senkung von Kosten, Energieverbrauch und Wärme Oracle im Auto? 45

43 Smartcards Chipkarten mit geringer Rechenleistung und geringem Speicher, z. B. Bankkarte, Mensakarte, SIM- Karte, Gesundheitskarte Sehr wenig Speicher (24-48KB) Externe, unsichere Stromversorgung Schnelles Lesen aber sehr langsames Schreiben Beschränkte Rechenleistung Oft hohe Sicherheitsanforderungen IBM DB2 auf Bankkarte? 48

44 Datenmanagement auf Smartcards Transaktionen (ACID) Benutzerverwaltung, Datensicherheit und Datenschutz Recovery SQL Anfragen? 49

45 Einsatzbeispiel Sensornetzwerke Biotopüberwachung auf Great Duck Island zur Beobachtung des Brutverhalten von Seevögeln, 2002, UC Berkeley & Intel 50 batteriebetriebene Sensoren 51

46 Einsatzbeispiel Sensornetzwerke II Sensornetzwerk in Erdbebentestzentrum Mobile, autarke, leicht anzubringende Sensoren statt zentraler Verkabelung 52 Alte Zentralverkabelung

47 Datenmanagement bei Sensornetzwerken Ad-hoc Anfragen Aggregation, Anfragen über Raum und Zeit Unterschiedliche Rollen von Sensoren: Sensorknoten, Aggregationsknoten, Eingangsknoten Dynamisch ändernde Rollen 53

48 Besonderheiten Sensornetzwerke Ressourcenbegrenzung durch Batteriebetrieb Schwache Rechenleistung Kein kontinuierliches Senden von Messwerten Unsichere Übertragung, veränderliches Netzwerk Wenig Speicher ( kB) Verteiltes System, verteilte Transaktionen 54

49 Eingebettete Datenbanken in der Zukunft Ubiquitous Computing Bsp.: vernetzte Computer in Kleidung, Kühlschrank, Intelligent Home, Kaffeetasse Smart Dust 55

50 Invarianz-Gesetz: Monotones Wachstum der Datenhaltung 1 PB 1 TB 1 GB 1 MB 1 KB SQL-3 SQL-1 1-Relation 1-Tupel

51 Implementierung: State-of-the-Art Wenn überhaupt Variantenmanagement, dann mit #ifdef, C++- Templates, make, CVS Beispiel: Berkeley DB (mutex_int.h) #ifndef _DB_MUTEX_INT_H_ #define _DB_MUTEX_INT_H_ #ifdef HAVE_MUTEX_PTHREADS #include <pthread.h> #define MUTEX_FIELDS pthread_mutex_t mutex; /* Mutex. */ pthread_cond_t cond; /* Condition variable. */ #endif #ifdef HAVE_MUTEX_UI_THREADS #include <thread.h> #endif #ifdef HAVE_MUTEX_SOLARIS_LWP #include <synch.h> #define MUTEX_FIELDS lwp_mutex_t mutex; /* Mutex. */ lwp_cond_t cond; /* Condition variable. */ #endif #ifdef HAVE_MUTEX_UI_THREADS #include <thread.h> #include <synch.h> #define MUTEX_FIELDS mutex_t mutex; /* Mutex. */ cond_t cond; /* Condition variable. */ #endif #ifdef HAVE_MUTEX_AIX_CHECK_LOCK #include <sys/atomic_op.h> typedef int tsl_t; 60 #ifdef LOAD_ACTUAL_MUTEX_CODE #define MUTEX_INIT(x) 0 #define MUTEX_SET(x) (!_check_lock(x, 0, 1)) #define MUTEX_UNSET(x) _clear_lock(x, 0) #endif endif #

52 warum jetzt ein neuer Versuch? Erfahrung aus dem Betriebssystembereich Vor 25 Jahren: ähnliche Situation wie im DBMS- Bereich Neue Programmiertechniken (FOP, AOP) Zum Teil im Betriebssystem-Bereich entwickelt Dort erfolgreich eingesetzt Warum nicht auch für andere Infrastruktur-Software einsetzbar? 63

53 Gemeinsame Funktionalität von eingebetteten DBMS Was wird immer wieder gebraucht Speichermanagement (z.b. Einpassen auf Seiten) Katalog Anfrageverarbeitung (SQL parsen, Pläne erstellen und optimieren) Transaktionsverwaltung Zugriffsrechte Recovery Verschlüsselung DDL/DML/SQL Dialekte Nicht alle Systeme benötigen alle Features 64

54 Optimierung Unterschiedliche Varianten der gleichen Funktionalität, z. B. Optimiert für geringen Stromverbrauch Optimiert für Performance Optimiert für minimalen Footprint Spezielle Implementierung für Systembesonderheiten, z. B. kein RAM, keine/kaum Schreibzugriffe Unterschiedliche Architekturen, z. B. verteilt vs. stand-alone 65

55 Produktlinien Jeweils neu programmieren ist sowohl unwirtschaftlich als auch gefährlich Daher maßgeschneidertes Datenmanagement mit Produktlinien Aus wiederverwendbaren Teilen Die alternative Implementierungen haben können Anpassbar für spezielle Anwendungsfälle Nutzbar auch unter extremer Ressourcenbeschränkung 66

56 Zusammenfassung Maßgeschneiderte Datenhaltung nötig Große Datenmenge unter beschränkten Ressourcen Gemeinsame Funktionalität aber auch viele Unterschiede Produktlinien als Ausweg? 67

57 Ausblick Modellierung von Produktlinien mit Features Einfache Implementierungsstrategien Moderne Programmierparadigmen 68

58 Literatur Marko Rosenmüller, Thomas Leich, Sven Apel und Gunter Saake. Von Mini- über Micro- bis zu Nano- DBMS: Datenhaltung in eingebetteten Systemen. Datenbank Spektrum, 7(20), Feb Michael Stonebraker. Technical perspective - One size fits all: an idea whose time has come and gone. Communications of the ACM. 51(12), Surajit Chaudhuri, Gerhard Weikum. Rethinking Database System Architecture: Towards a Self-Tuning RISC-Style Database System. Proc. Int. Conf. Very Large Data Bases,

59 70 Herausforderungen

60 Variabilität = Komplexität 71

61 72

62 33 optionale, unabhängige Features eine maßgeschneiderte Variante für jeden Menschen auf dem Planten 73

63 320 optionale, unabhängige Features mehr Varianten als es Atome im Universum gibt! 74

64 75

65 76 Korrektheit?

66 Alle Kombinationen sinnvoll? 77

67 Wiederverwendung bei der Implementierung? Wo Fehler korrigieren? 78

68 Optimierung von nicht-funktionalen Eigenschaften SQLite ist eingebettetes und konfigurierbares Datenbanksystem Eingesetzt auf über 500 Millionen Systeme Konfigurierbar mittels 88 Kompilierungsoptionen Angenommen wir messen jede Variante von SQLite: 2 88 Varianten und 5 Minuten pro Messung (kompilieren + Benchmark) = 2 88 * 5min / 60 (per h) / 24 (per d) / 365 (per y) = y Jetzt 1.37 * Jahre Log. Zeitachse 79 Big bang Entstehung der Erde 9 * 10 9 Jahre Messung beendet: 2.9 * Jahren

69 Idee: Systematische Entwicklung von Softwareproduktlinien Jeweils neu programmieren ist sowohl unwirtschaftlich als auch gefährlich Daher maßgeschneiderte Software auf Basis von Softwareproduktlinien Aus wiederverwendbaren Teilen Die alternative Implementierungen haben können Anpassbar für spezielle Anwendungsfälle Nutzbar auch unter extremer Ressourcenbeschränkung 80

70 Application Eng. Domain Eng. Entwurf und Implementierung von Features Feature-Modell Wiederverwendbare Implementierungsartefakte Feature-Auswahl Generator Fertiges Program 81

71 Nicht-funktionale Eigenschaften Begrenzungen und Optimierung Optimiert für geringen Stromverbrauch Optimiert für Performance Optimiert für minimalen Footprint Spezielle Implementierung (z. B. kein RAM, wenig Schreibzugriffe) 82

72 Implementierung: State of the Art Wenn überhaupt Variantenmanagement, dann mit #ifdef, Templates, make, CVS Beispiel: Berkeley DB (mutex_int.h) #ifndef _DB_MUTEX_INT_H_ #define _DB_MUTEX_INT_H_ #ifdef HAVE_MUTEX_PTHREADS #include <pthread.h> #define #endif MUTEX_FIELDS pthread_mutex_t mutex; /* Mutex. */ pthread_cond_t cond; /* Condition variable. */ #ifdef HAVE_MUTEX_UI_THREADS #include <thread.h> #endif #ifdef HAVE_MUTEX_SOLARIS_LWP #include <synch.h> #define #endif MUTEX_FIELDS lwp_mutex_t mutex; /* Mutex. */ lwp_cond_t cond; /* Condition variable. */ #ifdef HAVE_MUTEX_UI_THREADS #include <thread.h> #include <synch.h> #define #endif MUTEX_FIELDS mutex_t mutex; /* Mutex. */ cond_t cond; /* Condition variable. */ #ifdef HAVE_MUTEX_AIX_CHECK_LOCK #include <sys/atomic_op.h> typedef int tsl_t; 83 #ifdef LOAD_ACTUAL_MUTEX_CODE #define MUTEX_INIT(x) 0 #define MUTEX_SET(x) (!_check_lock(x, 0, 1)) #define MUTEX_UNSET(x) _clear_lock(x, 0) #endif endif #

73 Implementierung und Wartbarkeit? 84 class Stack { void push(object o #ifdef SYNC, Transaction txn #endif ) { if (o==null #ifdef SYNC txn==null #endif ) return; #ifdef SYNC Lock l=txn.lock(o); #endif elementdata[size++] = o; #ifdef SYNC l.unlock(); #endif firestackchanged(); } }

74 SPL-Implementierung Verschiedene Wege SPLs zu implementieren In dieser Vorlesung betrachten wir u.a. Versionsverwaltungssysteme Präprozessoren Komponenten Frameworks/Plugins Feature-orientierte Programmierung Aspekt-orientierte Programmierung 85

75 Wieviel Variabilität ist sinnvoll? Entwicklungskosten Investitionskosten Wartungskosten Logistikkosten Fertigungskosten (geringe Stückz.) 86

76 Schwerpunkte Maßgeschneiderte Software als Ziel Feature als zentrales Konzept Implementierung von Features steht im Vordergrund Viel Quelltext, diverse Paradigmen und Sprachen 91