Softwareproduktlinien Teil 1: Einführung und Überblick

Transkript

1 Softwareproduktlinien Teil 1: Einführung und Überblick Christian Kästner (Universität Marburg) Sven Apel (Universität Passau) Gunter Saake (Universität Magdeburg) 1

2 Agenda Formales, Organisatorisches Kurzeinführung in das Themengebiet 2

3 3 Hintergrund

4 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] 4

5 Produktlinien in der Industrie 5

6 Auto Produktlinie 6

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

8 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

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

10 Weitere Produktlinien 10

11 Weitere Produktlinien 11

12 Weitere Produktlinien

13 Massenproduktion 13

14 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) 14 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

15 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

16 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, 16

17 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) 17

18 Teil 2 Maßgeschneidertes Datenmanagement Gunter Saake (Universität Magdeburg) Christian Kästner (Universität Marburg)

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

20 Kommerzielle DBMS 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 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

21 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?

22 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?

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

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

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

26 Datenmanagement bei Sensornetzwerken Ad hoc Anfragen Aggregation, Anfragen über Raum und Zeit

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

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

29 Invarianz Gesetz: Monotones Wachstum der Datenhaltung 1 PB 1 TB 1 GB 1 MB 1 KB SQL-3 SQL-1 1-Relation 1-Tupel Mobile Data Embedded Data Personal Data (PC) Business Applications Ubiquitous Smart Dust

30 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; #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

31 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?

32 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

33 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

34 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

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

36 Ausblick Modellierung von Produktlinien mit Features Einfache Implementierungsstrategien Moderne Programmierparadigmen

37 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, 2000

38 38 Herausforderungen

39 Variabilität t = Komplexität

40

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

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

43 2000 Features Features

44 Korrektheit?

45 Alle Kombinationen sinnvoll? 45

46 Wiederverwendung bei der Implementierung? Wo Fehler korrigieren?

47 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

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

49 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 49