Zusammenfassung und Ausblick

Transkript

1 Betriebssystemtechnik Operating System Engineering (OSE) Zusammenfassung und Ausblick Überblick Zusammenfassung: Software-Produktlinien Prinzipien Methoden Werkzeuge Herausforderungen für die Zukunft Automatische Kombination und Integration Beherrschbarkeit nicht-funktionaler CiAO Olaf Spinczyk 2 Motivation Betriebssysteme für eingebettete Systeme Spezielle Hardware Markt mit > 100 RTOS Spezielle Anwendungen > 50% Eigenentwicklungen das Rad wird neu erfunden auch die selben Fehler werden wiederholt oftmals bietet ein BS Hersteller mehrere Systeme an mit getrennter Code-Basis getrieben durch die speziellen Anforderungen seiner Kunden 2007 Olaf Spinczyk 3 Software-Produktlinien (Software-PL) Organisierte Wiederverwendung durch die aktive Gestaltung einer gemeinsamen Plattform für aktuelle und künftige Produkte Existierender Code Domänenwissen Produktspezifische Anforderungen Domain Engineering Plattform Artefakte (assets) Application Engineering neues Produkt Im Domain Engineering werden die gemeinsamen und variablen Artefakte, die Bestandteile der Plattform, entwickelt. Im Application Engineering werden einzelne Produkte der Produktlinie entwickelt bzw. abgeleitet. Die Produkte werden [] konfiguriert, so dass nur in geringem Maße produktspezifische Softwareentwicklung notwendig wird Olaf Spinczyk 4 [1] [1]

2 Überblick: Software-Produktlinien Überblick: Software-Produktlinien Konkretes Problem... PL-Architekt / Entwickler Referenzarchitektur / Merkmalimplemente A B C Konkrete Lösung Konkretes Problem... Prinzipien Methoden Werkzeuge PL-Architekt / Entwickler Referenzarchitektur / Merkmalimplemente A B C Konkrete Lösung D D gewünschte tatsächliche gewünschte tatsächliche 2007 Olaf Spinczyk Olaf Spinczyk 6 Beschreibung des s Beschreibung des s Merkmalmodell (feature model) [2] Gerichteter, azyklischer Graph Beschreibt die möglichen Ausprägungen eines Konzepts anhand von Gemeinsamkeiten und Unterschieden Plattform Komponentenlager / -framework Implementierung der Konzepte und Merkmale PL-Architekt / Entwickler Referenzarchitektur / Merkmalimplemente Konzeptknoten (kurz Konzept ) C Familienmodell Abbildung aus Komponentenlager in den (von Artefakten auf Merkmale): A M Merkmalknoten (kurz Merkmale ) Eventuell über zusätzliche Transformationen: (A T) M 2007 Olaf Spinczyk Olaf Spinczyk 8

3 A B D C Beschreibung des s Konkretes Problem, konkrete Lösung Plattform Komponentenlager / -framework Problem: Trennung der Belange Implementierung der Konzepte und Merkmale Ideal: Jedes Artefakt ist genau einem Merkmal PL-Architekt / Entwickler Referenzarchitektur / Merkmalimplemente Merkmalauswahl Konkretes Problem gewünschte Konkrete Lösung zugeordnet: A M ist rechtseindeutig Familienmodell Realität: #ifdef-hölle Abbildung aus Komponentenlager in den (von Im Rahmen Artefakten von auf Merkmale): Betriebssystemtechnik wurden A verschiedenste M Werkzeuge und Sprachen betrachtet, die hier Besserung versprechen. Insbesondere AOP mit Eventuell C++. über zusätzliche Transformationen: (A T) M Generierter Quellcode-Baum tatsächliche 2007 Olaf Spinczyk Olaf Spinczyk 10 Bau von Produktlinienkomponenten Welcher Mechanismus ist wofür? erfordert Mechanismen zur Anpassung Präprozessoren (PP) - XVCL Generatoren (GEN) - pure::variants Klassenaliase Weber, Aspektorientierte Programmierung (AOP) - C++ Generische Programmierung (GP) - C++ Templates Objektorientierte Programmierung (OOP) - virtuelle Funktionen und Vererbung in C++ Die Komponenten einer Produktlinienplattform werden konfiguriert, übersetzt und zur gebracht. Auf jeder Ebene, auch im laufenden System, gibt es Variabilität und sentscheidungen. Produkt in Plattform- Was benutzt man wofür? 2007 Olaf Spinczyk Olaf Spinczyk 12

4 Welcher Mechanismus ist wofür? Welcher Mechanismus ist wofür? Anwender, Ereignisse Anwendung Anwendung Produkt in Plattform- Bei jedem Übergang zwischen den Ebenen gibt es eine - Beziehung. Welche gewählt wird, entscheidet (je nach Ebene) z.b. die Merkmalauswahl, die Anwendung durch instanziierte Templates und Typen sowie aufgerufene Funktionen oder zur Laufzeit der Anwender bzw. externe Ereignisse, durch die das Programm sein Verhalten ändert. Anwender, Ereignisse Anwendung Anwendung Produkt in Synth. Objects Generator Plattform- geeignete Mechanismen OOP (dynamisches Binden), Indirektionen, Attribute, GP (Template-iierung), AOP (. abstr. Aspekte), OOP (Vererbung), Binder (function level linking), Konkretes Problem gewünschte Konkretes Problem gewünschte PP, GEN, Dateiauswahl, AOP (Aspektselektion), FOP, 2007 Olaf Spinczyk Olaf Spinczyk 14 Welcher Mechanismus ist wofür? Welcher Mechanismus ist wofür? geeignete Mechanismen geeignete Mechanismen Anwendung Produkt in OOP (dynamisches Binden), Indirektionen, Attribute, Anwendung Produkt in OOP (dynamisches Binden), Indirektionen, Attribute, auswahl beeinflusst Variabilität der höheren Ebenen! Plattform- GP (Template-iierung), AOP (. abstr. Aspekte), OOP (Vererbung), Binder (function level linking), Mechanismen einer bestimmten Ebene können auch die Variabilität unterer Ebenen realisieren. Plattform- GP (Template-iierung), AOP (. abstr. Aspekte), OOP (Vererbung), Binder (function level linking), Beispiel: die der Plattform könnte eine Funktionen, eine Klassenhierarchie oder eine Template-Bibliothek liefern. PP, GEN, Dateiauswahl, AOP (Aspektselektion), FOP, Beispiel: statt Klassen statisch mit Policies zu parametrisieren könnte man auch das dynamische Strategy Muster verwenden. PP, GEN, Dateiauswahl, AOP (Aspektselektion), FOP, 2007 Olaf Spinczyk Olaf Spinczyk 16

5 Welcher Mechanismus ist wofür? Zwischenfazit: Stand der Kunst Mechanismen höherer Ebenen sind i.d.r. teurer, inbes. Laufzeitmechanismen. Beispiel: dynamisches Binden kostet mehr Zeit und Code als statisches. Templates können den Code aufblähen. Eine feste Klassenauswahl tut das nicht. Anwendung Produkt in Plattform- geeignete Mechanismen OOP (dynamisches Binden), Indirektionen, Attribute, GP (Template-iierung), AOP (. abstr. Aspekte), OOP (Vererbung), Binder (function level linking), PP, GEN, Dateiauswahl, AOP (Aspektselektion), FOP, in der Betriebssystem-Produktlinienentwicklung Insgesamt: durchaus erfolgreich OSEK und ecos sind erfolgreiche Beispiele aus dem Bereich eingebetteter Systeme Im Detail: durchaus nicht trivial es gibt viele Möglichkeiten, Plattformkomponenten zu realisieren grundsätzlich sollte gelten: sentscheidungen so früh wie möglich treffen (z.b. statisch statt dynamisch) - spart Ressourcen und erspart dem Anwender unnötige Komplexität Es bleiben viele Herausforderungen (Automatisches) Finden der optimalen Variante Komposition von Produktlinien nicht-funktionaler 2007 Olaf Spinczyk Olaf Spinczyk 18 Herausforderung: Finden der optimalen Variante Gegeben Anwendung (z.b. Steuergerät) Feingranular konfigurierbare Produktlinie (z.b. PURE: ~250 konfigurierbare Merkmale) Gesucht Optimale Variante (=Konfiguration) Entsprechend den Anforderungen der Anwendung Herausforderung: Finden der optimalen Variante Gegeben Anwendung (z.b. Steuergerät) Feingranular konfigurierbare Produktlinie (z.b. PURE: ~250 konfigurierbare Merkmale) Gesucht Ziel: Automatische Merkmalauswahl Optimale Variante (=Konfiguration) Entsprechend den Anforderungen der Anwendung Merkmale der PL oft begrifflich zu weit entfernt von den Anforderungen der Anwendung allocation strategy Merkmale der PL oft begrifflich zu weit entfernt von den Anforderungen der Anwendung allocation strategy Unterschiede nur für Insider erkennbar first fit best fit worst fit Unterschiede nur für Insider erkennbar first fit best fit worst fit 2007 Olaf Spinczyk Olaf Spinczyk 20

6 Herausforderung: Komposition von Produktlinien Herausforderung: Komposition von Produktlinien Existierende Produktlinien sind Insellösungen Existierende Produktlinien sind Insellösungen eng abgesteckte Domäne eng abgesteckte Domäne implementierungsnahe Merkmale eigene Modellierungssprachen und -konzepte implementierungsnahe Merkmale Ziel: Kombinierbare Produktlinien eigene Modellierungssprachen und -konzepte eigene swerkzeuge eigene swerkzeuge 2007 Olaf Spinczyk Olaf Spinczyk 22 Szenario: Komposition von Produktlinien Schicht 3: Anwendungen Schicht 2: Middleware Auswirkungen Schicht 1: Betriebssystem Schicht 0: Hardware Referenzarchitektur / Merkmalimpl. Auswirkungen automatische Konfiguration 2007 Olaf Spinczyk 23 Referenzarchitektur / Merkmalimpl. automatische Konfiguration Referenzarchitektur / Merkmalimpl. Herausforderung: nicht-funktionale Als nicht-funktional werden jene eines Softwaresystems bezeichnet, die nicht den eigentlichen Funktionsumfang betreffen, jedoch beim Betrieb der Software beobachtbar sind. Performanz Ressourcenverbrauch Skalierbarkeit Vorhersagbarkeit Latenz 2007 Olaf Spinczyk 24

7 Nicht-funktionale sind Nicht-funktionale sind erfolgsbestimmend TollCollect 1 funktionierte prima erfolgsbestimmend TollCollect 1 funktionierte prima oft dominierend über funktionale emergent nicht sichtbar auf der Ebene einzelner Komponenten ergeben sich plötzlich aus der Gesamtkomposition nicht trennbar von der Implementierung funktionaler Belange Effekte des ohne Entsprechung im nicht direkt konfigurierbar dominieren oft funktionale Ansatz: Indirekte Beinflussung emergent über Merkmale mit bekannt positiven Auswirkungen nicht sichtbar auf der Ebene einzelner Komponenten auf nicht-funktionale ergeben sich plötzlich aus der Gesamtkomposition über konfigurierbare Architektureigenschaften nicht trennbar von der Implementierung funktionaler Belange Rückabbildung in den Effekte des ohne Entsprechung im Metriken und Heuristiken erforderlich nicht direkt konfigurierbar 2007 Olaf Spinczyk Olaf Spinczyk 26 E x e c u t i o n L e v e l Thread preemtable interruptable Epilogue non preemtable interruptable non preemtable non interruptable Beispiel: Interrupt Synchronisation Configuration 1 hard synchronisation μ-controller OS Handler Configuration 2 pro-/epilogues Linux, NT, PURE, Epilogue Prologue Configuration 3 driver threads L4Ka, Driver Thread Dispatcher daniel.lohmann@cs.fau.de 27 Configuration 4 irq pseudo-threads Solaris Thread Thread Thread Thread lock irq lock epilogues delayed (epilogue) lock irq message delayed (message) Thread Pseudo- Thread may block implicit transition (on demand) Architekturneutrales Treibermodell Methoden werden Synchronisationsdomänen zugeordnet synchronized - Methoden sind durch ein Software-Protokoll geschützt - Aufruf von der Ebene kann verzögert werden - Aufruf von der Thread Ebene erfordert Sperren blocked - Methoden sind auf der Ebene geschützt - Aufrufe von der Thread Ebene erfordern eine Sperre transparent - Methoden brauchen nicht geschützt werden - von jeder Ebene aufrufbar Aspekte fügen die nötigen Synchronisationsaufrufe hinzu! daniel.lohmann@cs.fau.de 28

8 Beispiel: ein Wecker class Timer { // state public: void init( long time ); long get() const; void add_event(const EventCallback* cb); private: void tick(); void process_events(); void handler() { tick(); process_events(); } // what belongs to which synchronization class pointcut int_handler() = "% Timer::handler()"; pointcut blocking() = "% Timer::init()" "% Timer::tick()"; pointcut transparent() = "% Timer::get()const"; pointcut synchronized() = "% Timer::%()" &&!int_handler() &&!blocking() &&!transparent(); }; daniel.lohmann@cs.fau.de 29 Harte Synchronisation aspect Configuration1 { pointcut block() = Timer::synchronized() Timer::blocking(); advice call( block() &&!within( block() Timer::int_handler() ) : around() { disable_int(); tjp->proceed(); enable_int(); } }; daniel.lohmann@cs.fau.de 30 Pro-/Epilogue Modell aspect Configuration2 { pointcut block() = Timer::blocking(); pointcut delay() = Timer::synchronized(); Zusammenfassung: Betriebssystem-PL Anwendung im Kleinen: Erfolgreich das sollten die Übungen zur Lehrveranstaltung gezeigt haben advice call( block() ) &&!within( block() Timer::int_handler() ) : around() { disable_int(); tjp->proceed(); enable_int(); } advice call( delay() ) &&!within( "% Timer::%()" ) : around() { lock_epilogues(); tjp->proceed(); leave_epilogues(); } advice call( Timer::synchronized() ) &&!within( Timer::synchronized() ) && cflow( execution( Timer::int_handler())): around(){ add_epilog (tjp->action ()); } }; daniel.lohmann@cs.fau.de 31 Anwendung im Großen: Viele offene Fragen Variantenvielfalt Beherrschbarkeit nicht-funktionaler Belange Integration und Komposition unterschiedlicher PL Methodisch steht die BS-PL-Entwicklung erst am Anfang! Mithilfe erwünscht! 2007 Olaf Spinczyk 32

9 Literatur [1] G. Böckle, P. Knauber, K. Pohl, K. Schmid (Hrsg.). Software-Produktlinien. dpunkt.verlag, ISBN [2] K. Czarnecki und U.W. Eisenecker. Generative Programming Methods, Tools, and Applications. Addison-Wesley, ISBN [3] pure-systems GmbH. Variantenmanagement mit pure-variants. Technical White Paper, Olaf Spinczyk 33