Software ubiquitärer Systeme

Transkript

1 Software ubiquitärer Systeme Betriebssystem-Produktlinien (und deren statische Konfigurierung) Olaf Spinczyk Arbeitsgruppe Eingebettete Systemsoftware Lehrstuhl für Informatik 12 TU Dortmund 1

2 Inhalt Wiederholung Architekturtreiber Familienbasierter Betriebssystementwurf EPOS: Anwendungsgetriebene Produktableitung PURE:Merkmalgetriebene Produktableitung Zusammenfassung Anwendung/Programmierung Datenhaltung Middleware Betriebssystem Hardware 03.4 Betriebssystem-Produktlinien 2

3 Inhalt Wiederholung Architekturtreiber Familienbasierter Betriebssystementwurf EPOS: Anwendungsgetriebene Produktableitung PURE: Merkmalgetriebene Produktableitung Zusammenfassung 03.4 Betriebssystem-Produktlinien 3

4 Software-Produktlinienentwicklung Existierender Code Domänenterminologie Referenzanforderungen Feedback/Anpassungen Reverse Architecting Wiederverwendbare Komponenten Requirements Traceability Traceability Komponenten Applikationsimplement. Domänenwissen Referenzarchitektur Produktspezifische Anforderungen Referenzprozess für die Software-Produktlinienentwicklung [1] Domänenanalyse Domänenentwurf Domänenimplement. Applikationsanalyse Applikationsentwurf : Domain Engineering : Application Engineering 03.4 Betriebssystem-Produktlinien 4

5 Merkmalgetriebene Produktableitung... eine weitere Indirektionsstufe concrete problem application-specific code application developer platform customizer f2 f6... required API subset required features features and dependencies concrete solution PL platform instance product derivation techniques solution space PL platform problem space f4 f2 f5 f1 f3 f6 f7 domain expert 03.4 Betriebssystem-Produktlinien 5

6 Inhalt Wiederholung Architekturtreiber Familienbasierter Betriebssystementwurf EPOS: Anwendungsgetriebene Produktableitung PURE: Merkmalgetriebene Produktableitung Zusammenfassung 03.4 Betriebssystem-Produktlinien 6

7 Architekturtreiber für BS-Familien Konfigurierbarkeit geringer Konfigurationsbedarf innerhalb der Komponenten große Variabilität (viele Alternativen) feine Granularität (in kleinen Stufen Funktionen weglassen können) minimaler Ressourcenverbrauch insbesondere Code-Größe keine Voraussetzungen hinsichtlich Infrastruktur z.b. keine Interprozesskommunikation Beherrschung der Komplexität durch Abstraktion Echtzeitfähigkeit Fehlertoleranz Energiesparen 03.4 Betriebssystem-Produktlinien 7

8 Inhalt Wiederholung Architekturtreiber Familienbasierter Betriebssystementwurf EPOS: Anwendungsgetriebene Produktableitung PURE: Merkmalgetriebene Produktableitung Zusammenfassung 03.4 Betriebssystem-Produktlinien 8

9 Familienbasierter Entwurf die Grundlage mehrerer konfigurierbarer Betriebssystemfamilien seit den 70er Jahren Rather than write programs that perform the transformation from input to output data, we design software machine extensions that will be useful in writing many such programs. D. L. Parnas [5] 03.4 Betriebssystem-Produktlinien 9

10 Beispiel FAMOS [4] a time sharing system user interface a batch system job control language file systems swapping disk i/o a process control system special devices process creation address space creat. synchronization process managem. address spaces hardware Habermann, Betriebssystem-Produktlinien 10

11 Das Modell der funktionalen Hierarchie... 4 process manager file system 3 clock driver irq monitor disk driver 2 process scheduler disk access Betriebssystem-Produktlinien 11

12 Funktionale Hierarchie Elemente Funktionen elementare Systembausteine der Software (Entwurfsebene) logische Funktionen... 4 process manager file system 3 clock driver irq monitor disk driver 2 process scheduler disk access Betriebssystem-Produktlinien 12

13 Funktionale Hierarchie Elemente Funktionale Abhängigkeiten logische Abhängigkeiten zwischen Systembausteinen ( verwendet ) müssen einen azyklischen Graphen ergeben... 4 process manager file system 3 clock driver irq monitor disk driver 2 process scheduler disk access Betriebssystem-Produktlinien 13

14 Funktionale Hierarchie Elemente Ebenen Gruppierung zusammenhängender Funktionen Ebene 0 ist die Hardware Ebenen 1...n fügen virtuelle Hardware als minimale Erweiterungen hinzu... Funktionen der Ebene n kennen alle Funktionen der Ebenen 0...n 4 process manager file system 3 clock driver irq monitor disk driver 2 process scheduler disk access Betriebssystem-Produktlinien 14

15 Funktionale Hierarchie Vorteile verständlich process manager file system gut für bottom-up Entwicklung geeignet clock driver irq monitor disk driver feingranulare Konfigurierbarkeit durch minimale Erweiterungen process scheduler disk access bedingt keine speziellen Implementierungsmechanismen It is the system design which is hierarchical, not its implementation Habermann, 1976 [4] 03.4 Betriebssystem-Produktlinien 15

16 Familienbasierter Entwurf: Vorgehen minimal subset of system functions allgemeine Funktionen, die von den weiter spezialisierten Varianten benötigt werden implementieren Mechanismen in Form fundamentaler Grundbausteine minimal system extensions Verwendung, Spezialisierung oder Anpassung der fundamentalen Systemfunktionen Kapselung der strategischen und anwendungsspezifischen Entwurfsentscheidungen Schrittweise bottom-up entwickelt, aber top-down getrieben decisions which restrict the family are postponed as far as possible [4] 03.4 Betriebssystem-Produktlinien 16

17 Familienbasierter Entwurf: Diskussion Pro: Konfigurierung durch Weglassen feingranulare Konfigurierbarkeit Contra: viel Erfahrung und Weitblick nötig minimale Erweiterungen erfordern viel Geduld - modernere Ansätze versuchen, auch zu viel an Variabilität zu vermeiden Merkmalmodelle konfigurierbare Funktionen werden nicht berücksichtigt querschneidende Belange und nicht-funktionale Eigenschaften lassen sich nicht darstellen 03.4 Betriebssystem-Produktlinien 17

18 Inhalt Wiederholung Architekturtreiber Familienbasierter Betriebssystementwurf EPOS: Anwendungsgetriebene Produktableitung PURE: Merkmalgetriebene Produktableitung Zusammenfassung 03.4 Betriebssystem-Produktlinien 18

19 EPOS [7] A. Fröhlich, 1999 GMD FIRST Berlin Zieldomäne: eingebettete und parallele Anwendungen Ansatz: Application-Oriented System Design Szenario-unabhängige Systemabstraktion Szenarioadapter Inflated Interfaces statische Anwendungsanalyse statische Template-Metaprogrammierung 03.4 Betriebssystem-Produktlinien 19

20 EPOS - Systemabstraktionen application ready unabhängig vom Ausführungsszenario Beispiele: ein Faden mit einem bestimmten Scheduling Verhalten - aber KEIN Faden für eine Einprozessoroder Multiprozessor-Umgebung Mailboxes für Interprozesskommunikation Mutexes für Prozesssynchronisation System Abstraction system micro-components 03.4 Betriebssystem-Produktlinien 20

21 EPOS - Szenarioadapter passt eine Systemabstraktion an eine bestimmte Ausführungsumgebung an. sorgt auch für die Anpassung der Mikro-Komponenten in den Systemabstraktionen Scenario Adapters Beispiele: ein SMP Adapter - implementiert Multiprozessorsynchronisation ein RPC Adapter - implementiert transparents un-/marshalling 03.4 Betriebssystem-Produktlinien 21

22 EPOS Anforderungsanalyse (1) die Anwendungen werden gegen Inflated Interfaces programmiert wohl bekannt leicht verständlich nicht alle Systemvarianten haben eine Implementierung für die gesamte Schnittstelle Anhand... der verwendeten Schnittstellen, der referenzierten Funktionen und der Art der Referenzierung kann auf die geeignetste Systemkonfiguration geschlossen werden statische Anwendungsanalyse 03.4 Betriebssystem-Produktlinien 22

23 EPOS Anforderungsanalyse (2) complex application program code = new Segment(buffer, size); task = new Task(code, data); thread = new Thread(task, &entry_func, priority, SUSPENDED, arguments); mutex->entry(); Mailbox mailbox; mailbox >> message; File file(name); file << mailbox; tasks mailboxes threads syntactic analyzer files mutex segments 03.4 Betriebssystem-Produktlinien 23

24 EPOS Anforderungsanalyse (3) real application program (MPI) Channel link(destination); link << message; syntactic analyzer links flat memory 03.4 Betriebssystem-Produktlinien 24

25 EPOS Szenarioauswahl leider lassen sich nicht alle nötigen Konfigurationsinformationen mit Hilfe der Inflated Interfaces automatisch ableiten Zielhardware zu verwendende Kommunikationsprotokolle Dateisystemtyp... durch manuelle Auswahl wird der passende Szenario- Adapter und die Systemkonfiguration bestimmt durch die Vorauswahl wurde die Komplexität allerdings erheblich reduziert tasks mailboxes threads execution scenario required Inflated interfaces + = files monitors segments 03.4 Betriebssystem-Produktlinien 25

26 EPOS Fazit EPOS versucht, es dem Anwendungsprogrammierer leicht zu machen ( application-oriented ) standardisierte Schnittstellen für alle Mitglieder der (Teil-)Familien automatische Analyse der Anwendung Konfigurierungswerkzeuge technisch basiert EPOS auf generischer und generativer Programmierung in C++ application interfaces scenario adapters system microcomponents system abstractions 03.4 Betriebssystem-Produktlinien 26

27 Inhalt Wiederholung Architekturtreiber Familienbasierter Betriebssystementwurf EPOS: Anwendungsgetriebene Produktableitung PURE: Merkmalgetriebene Produktableitung Zusammenfassung 03.4 Betriebssystem-Produktlinien 27

28 PURE W. Schröder-Preikschat, Universität Potsdam und Magdeburg Zieldomäne: kleinste eingebettete Systeme hochgradige Konfigurierbarkeit Ansatz: familienbasierter Entwurf Parnas u. Habermann, Vererbung (C++) Umfang: ca. 900 Dateien, 300 Klassen Herausforderungen: Beherrschung der Konfigurationsvielfalt Umsetzung im Programmcode 03.4 Betriebssystem-Produktlinien 28

29 OO vs. familienbasierter Entwurf Vererbung kann als Vehikel für die schrittweise Erweiterung genutzt werden minimal subset incremental system design minimal extension program families base class inheritance derived class object orientation [6] Pro funktionale Hierarchien lassen sich (relativ) leicht in eine Modulstruktur transformieren Contra Entwurf wird leicht als schlechter OO-Entwurf missverstanden 03.4 Betriebssystem-Produktlinien 29

30 PURE - Größen... durchaus mit denen von OSEK-Systemen vergleichbar Inlining dank C++ und Inline Optimierungswerkzeug kaum virtuelle Funktionen durch den familien-basierten Entwurf preemptive 4062 preemption non-preemptive 1699 cooperative 1648 scheduling dispatching coordinative 2306 propagation interruptive 1268 exclusive 434 objectification synchronization interruption 03.4 Betriebssystem-Produktlinien 30

31 PURE die Thread-Hierarchie... extrem feingranular aufgebaut: 13 Ebenen! unterstützt z.b. diverse Scheduling-Strategien Klassenaliase konfigurieren die Schichten anfangs über Präprozessor- Konfigurationsflags durch leere (aber kompatible) Klassen wie Deafmute oder Stoic können Schichten auch inaktiv sein Beherrschbar nur mit Werkzeugunterstützung! 03.4 Betriebssystem-Produktlinien 31

32 Wdh.: Produktlinienentwicklung Problemraum Lösungsraum Domänenexperte f2 f1 f3... Aspect Aspect Aspect PL-Architekt / Entwickler Konkretes Problem f4 f5 f6 Merkmale und Abhängigkeiten f2 f6... f7 Prinzipien Methoden Werkzeuge Class Class Class Referenzarchitektur / Merkmalimplemente A B C Konkrete Lösung D Applikationsentwickler gewünschte Eigenschaften tatsächliche Eigenschaften 03.4 Betriebssystem-Produktlinien 32

33 Werkzeugunterstützung Beispiel: pure::variants [2, 3] zusätzliche (programmierbare) Ebene oberhalb der Komponenten flexible Generierungs- und Transformationsmöglichkeiten automatisierte Abbildung von Anforderungen (z.b. Merkmalselektion) auf Softwarevarianten 03.4 Betriebssystem-Produktlinien 33

34 pure::variants Problemraum Featuremodell Lösungsraum Familienmodell pure::variants Variantenmodell Einzelnes Problem Variantenrealisierung Einzelne Lösung In der Übung werden diese Konzepte ebenfalls verwendet. Nur das Werkzeug ist ein anderes Betriebssystem-Produktlinien 34

35 p::v Featuremodell (1) Ein Featuremodell enthält nur Elemente der Klasse ps:feature Es gibt 4 Arten von Featuregruppen notwendig (ps:mandatory) [n] optional (ps:optional) [0-n] alternativ (ps:alternative) [1] oder (ps:or) [1-n]* Jedes Feature kann von jeder Gruppenart maximal eine Gruppe besitzen 03.4 Betriebssystem-Produktlinien 35

36 p::v Featuremodell (2) Darstellung der Eigenschaften in Baumstruktur Icons stellen Gruppenart dar Kreuze stehen für mehrfache Auswahl: 1-3 Meßsensoren möglich Doppelpfeile zeigen Alternativen an: Datentransfer entweder USB oder seriell Fragezeichen kennzeichnen Optionen: Debugsupport ist möglich aber nicht notwendig 03.4 Betriebssystem-Produktlinien 36

37 p::v Featuremodell (3) Beziehungen zwischen Features (und auch anderen Modellelementen) Gegenseitiger Ausschluß (ps:conflicts, ps:discourages) Implikation (ps:requires, ps:required_for, ps:recommends, ps:recommended_for)... (erweiterbar) Semantik von 1:n Beziehung unterschiedlich ps:conflicts und Co. : AND (Fehler, falls alle n selektiert sind) ps:requires und Co. : OR (Fehler, falls keines der n selektiert ist) 03.4 Betriebssystem-Produktlinien 37

38 p::v Familienmodell (1) Darstellung eines Lösungsraums Hierarchische Gruppierung von Elementklassen Komponenten (component) enthalten Teile (part) Teile enthalten weitere Teile und/oder Quellen (source) Teile und Quellen sind getypt Typen werden in der Transformation ausgewertet Typ gibt notwendige und optionale Attribute vor Restriktion ist Vorbedingung für Auswahl 03.4 Betriebssystem-Produktlinien 38

39 p::v Familienmodell (2) Die Familienmodelle erfassen den Aufbau der Lösung von der abstrakten variablen Architektur bis hin zu den notwendigen Dateien. Neben der hier gezeigten Möglichkeit, die Informationen direkt in pure::variants zu bearbeiten, kann auch eine Koppelung mit anderen Modellierungswerkzeugen erfolgen. Die Icons stellen den Typ des Modellelements dar. Hier eine Komponente. Diese Typen sind frei definierbar (entsprechend der Architektur). Diese Regeln steuern die Auswahl von Lösungselementen. Hier soll die Komponente AirPressureSensors nur dann zur Lösung gehören, wenn das entsprechende Feature gleichen Namens gewählt wird Betriebssystem-Produktlinien 39

40 p::v Konfigurationsraum (1) (configuration space) Zusammenstellung von Modellen für die gemeinsame Konfiguration Feature- und Familienmodelle können in mehreren Konfigurationsräumen verwendet werden speichert die Parameter für die (optionale) Transformation enthält beliebig viele Variantenbeschreibungen 03.4 Betriebssystem-Produktlinien 40

41 p::v Konfigurationsraum (2) In pure::variants werden Produktvariabilitäten (Featuremodelle) und Lösungsarchitekturen (Familienmodelle) flexibel zu Produktlinien kombiniert. Eine Produktlinie kann aus beliebig vielen Modellen bestehen. Der Configuration Space verwaltet diese Informationen und fasst die Varianten einer Produktlinie zusammen. Der Configuration Space Product Variants fasst die Variantendefinitionen für die Produkte zusammen. Jedes Modell repräsentiert eine Variante Diese Variantenmatrix ermöglicht einen Überblick über Unterschiede und Gemeinsamkeiten der Produktvarianten 03.4 Betriebssystem-Produktlinien 41

42 p::v Variantenbeschreibung (1) (variant description model) definiert eine Variante aus den Möglichkeiten eines Konfigurationsraums enthält alle gewählten Features alle durch Anwender spezifizierten Attributwerte 03.4 Betriebssystem-Produktlinien 42

43 p::v Variantenbeschreibung (2) Die Variantenerstellung erfolgt durch Auswahl der gewünschten Features im Variantenmodell. pure::variants prüft die Auswahl interaktiv und löst oder meldet auftretende Probleme Betriebssystem-Produktlinien 43

44 p::v Modellauswertung 03.4 Betriebssystem-Produktlinien 44

45 p::v Variantenerstellung Die Variantenerstellung erfolgt durch Auswahl der gewünschten Features im Variantenmodell. pure::variants prüft die Auswahl interaktiv und löst oder meldet auftretende Probleme. Durch einen Doppelklick wird zur Problemstelle navigiert. Die Auswertung eines neuen Variantenmodells ergibt hier 2 vom Anwender zu lösende Probleme. In den beiden Mehrfachauswahlen wurde noch nichts ausgewählt Betriebssystem-Produktlinien 45

46 p::v Variantenerstellung Die Variantenerstellung erfolgt durch Auswahl der gewünschten Features im Variantenmodell. pure::variants prüft die Auswahl interaktiv und löst oder meldet auftretende Probleme. Die Auswahl von mindestens einem Feature (Pressure, LCD) löste das Problem Betriebssystem-Produktlinien 46

47 p::v Resultatsansicht Die Resultatsicht (Result view) stellt die errechnete Lösung in (konfigurierbarer) Form als Baum oder Tabelle dar. Export über das Kontextmenü möglich Betriebssystem-Produktlinien 47

48 p::v Variantentransformation Neben den Exportmöglichkeiten in verschiedene Formate wie HTML, CSV/Excel oder XML bietet pure::variants einen Mechanismus, mit dem aus Variantenmodellen die konkrete Lösung erzeugt wird. Dieser Transformationsmechanismus kann durch die Anwender beliebig erweitert und angepasst werden, sollten die Möglichkeiten der mitgelieferten Module nicht ausreichen. Eine Transformationskonfiguration wird einem Configuration Space zugeordnet. Die Module werden in der angegebenen Reihenfolge ausgeführt. Die Einbindung externer Werkzeuge ist einfach und schnell möglich. Mitgelieferte Module erlauben zum Beispiel die Erzeugung variantenspezifischer Dokumentation direkt aus Microsoft Word Dokumenten Betriebssystem-Produktlinien 48

49 p::v Standardtransformationen... erlauben im Wesentlichen: das Kopieren von Dateien in den Lösungsbaum das Zusammenstellen von Dateien aus Fragmenten das Erstellen von Links (nicht unter Windows) das Generieren von Flag-Files #ifndef flag_xxx #define flag_xxx #define XXX 1 #endif // flag_xxx das Generieren von Class Aliases #ifndef alias_yyy #define alias_yyy #include ZZZ.h typedef ZZZ YYY; #endif // alias_yyy 03.4 Betriebssystem-Produktlinien 49

50 Inhalt Wiederholung Architekturtreiber Familienbasierter Betriebssystementwurf Anwendungsgetriebene Produktableitung Merkmalgetriebene Produktableitung Zusammenfassung 03.4 Betriebssystem-Produktlinien 50

51 Zusammenfassung Familienbasierter Systementwurf eignet sich für den Bau feingranular konfigurierbarer BS-Produktlinien Schichtenarchitektur: Konfigurieren durch Weglassen Erfordert (zu) viel Weitsicht EPOS erweitert den Ansatz der applikationsgetriebenen Produktableitung Inflated Interfaces Statische Anwendungsanalyse PURE ist ohne merkmalbasierte Konfigurierung praktisch nicht beherrschbar Familienbasierter Entwurf mit OO umgesetzt pure::variants unterstützt... - die Erfassung von Domänenwissen - die Beschreibung des Lösungsraums (die Plattform ) - die Beschreibung konkreter Applikationsanforderungen - die Kontrolle der Lösung durch ein Resultatsmodell 03.4 Betriebssystem-Produktlinien 51

52 Literatur [1] G. Böckle, P. Knauber, K. Pohl, K. Schmid (Hrsg.). Software- Produktlinien. dpunkt.verlag, ISBN , [2] pure-systems GmbH. Variantenmanagement mit pure-variants. Technical White Paper, [3] pure-systems GmbH. pure::variants Eclipse Plugin. pure-variants. Manual, [4] A. N. Habermann, L. Flon, and L. Cooprider. Modularization and Hierarchy in a Family of Operating Systems. Communications of the ACM, 19(5): , [5] D. L. Parnas. Designing Software for Ease of Extension and Contraction. IEEE Transactions on Software Engineering, SE- 5(2): , [6] W. Schröder-Preikschat. The Logical Design of Parallel Operating Systems. Prentice Hall, ISBN , [7] A. A. Fröhlich, Application-Oriented Operating Systems. Sankt Augustin: GMD - Forschungszentrum Informationstechnik, 2001, ISBN Betriebssystem-Produktlinien 52