Software ubiquitärer Systeme (SuS) · 17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 10...

Software ubiquitärer Systeme (SuS)

Betriebssystem-Produktlinien(und deren statische Konfigurierung)

https://ess.cs.tu-dortmund.de/DE/Teaching/SS2017/SuS/

Olaf Spinczyk

[email protected]://ess.cs.tu-dortmund.de/~os

AG Eingebettete SystemsoftwareInformatik 12, TU Dortmund

mailto:[email protected]

17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 2

Inhalt● Wiederholung● Architekturtreiber● Familienbasierter Betriebssystementwurf● EPOS: Anwendungsgetriebene Produktableitung● PURE: Merkmalgetriebene Produktableitung● Zusammenfassung

HardwareHardware

BetriebssystemBetriebssystem

MiddlewareMiddleware

DatenhaltungDatenhaltung

Anwendung/ProgrammierungAnwendung/Programmierung


RequirementsRequirements KomponentenKomponentenTraceability Traceability

Domänen-analyseDomänen-analyse

Domänen-entwurfDomänen-entwurf

Domänen-implement.Domänen-implement.

Applikations-analyseApplikations-analyse

Applikations-entwurfApplikations-entwurf

Applikations-implement.Applikations-implement.

Referenzprozess für die Software-Produktlinienentwicklung [1]

ExistierenderCode

Domänen-wissen

Domänenterminologie

ReferenzanforderungenReferenz-architektur

Feedback/AnpassungenReverse Architecting

WiederverwendbareKomponenten

Produkt-spezifischeAnforderungen

: Domain Engineering : Application Engineering

Software-Produktlinienentwicklung


Merkmalgetriebene Produktableitung

concrete solutionconcrete solution

PL platform instancePL platform instanceconcrete problemconcrete problem

application-specificcode

application-specificcode

solution spacesolution space

PL platformPL platform

problem spaceproblem space

domain expert

f1

f7

f3f2

f6f5f4

features anddependencies

... eine weitere Indirektionsstufe

f2

f6...

requiredfeatures

platform customizer

application developer

requiredAPI subset product derivation

techniques


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


Familienbasierter Entwurf

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

● die Grundlage mehrerer konfigurierbarer„Betriebssystemfamilien“ seit den 70er Jahren


Beispiel – FAMOS [4]

address spacesaddress spaces

process managem.process managem.

synchronizationsynchronization

address space creat.address space creat.

process creationprocess creation

disk i/odisk i/o

swappingswapping

file systemsfile systems

special devicesspecial devices

job control languagejob control languageuser interfaceuser interface

a time sharing system a batch system

a process control system

hardwarehardwareHabermann, 1976


Das Modell der funktionalen Hierarchie

1

2

3

4

disk accessdisk access

irq monitorirq monitorclock driverclock driver disk driverdisk driver

process managerprocess manager file systemfile system

...

process schedulerprocess scheduler


Funktionale Hierarchie – Elemente

1

2

3

4




...


Funktionen elementare Systembausteine der Software (Entwurfsebene) „logische Funktionen“

Funktionen elementare Systembausteine der Software (Entwurfsebene) „logische Funktionen“



1

2

3

4




...


Funktionale Abhängigkeiten logische Abhängigkeiten zwischen Systembausteinen („verwendet“) müssen einen azyklischen Graphen ergeben

Funktionale Abhängigkeiten logische Abhängigkeiten zwischen Systembausteinen („verwendet“) müssen einen azyklischen Graphen ergeben



1

2

3

4




...


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

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


● verständlich

● gut für „bottom-up“-Entwicklung geeignet

● feingranulare Konfigurierbarkeitdurch „minimale Erweiterungen“

● bedingt keine speziellen Implementierungsmechanismen

It is the system design which is hierarchical,not its implementation. Habermann, 1976 [4]

Funktionale Hierarchie – Vorteile






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]


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


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


EPOS – Systemabstraktionen● „application ready“● unabhängig vom Ausführungs-

szenario● Beispiele:

– ein Faden mit einem bestimmtenSchedulingverhalten

● aber KEIN Faden für eine Einprozessor-oder Multiprozessor-Umgebung

– Mailboxes für Interprozesskommunikation– Mutexes für Prozesssynchronisation

System Abstraction

system micro-components


EPOS – Szenarioadapter● passt eine Systemabstraktion an

eine bestimmte Ausführungs-umgebung an

● sorgt auch für die Anpassungder Mikro-Komponenten in denSystemabstraktionen

● Beispiele:– ein SMP-Adapter

● implementiert Multiprozessorsynchronisation– ein RPC-Adapter

● implementiert transparentes un-/marshalling

Scenario Adapters


EPOS – Anforderungsanalyse (1)● die Anwendungen werden gegen Inflated Interfaces programmiert

– wohlbekannt– 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


EPOS – Anforderungsanalyse (2)

syntacticanalyzer

tasks

segments

threadsmailboxes

mutexfiles

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;


EPOS – Anforderungsanalyse (3)

flat memorylinks

syntacticanalyzer

real application program (MPI)

Channel link(destination);link << message;


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

reduziertexecution scenario

+ =tasks

segments

threadsmailboxes

monitorsfiles

required Inflated interfaces


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 EPOSauf generischer und generativerProgrammierung in C++

application

interfaces

scenario adapters

system micro-components

system abstractions


PURE● W. Schröder-Preikschat, 1995-2003

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


program families

OO vs. familienbasierter Entwurf● Vererbung kann als Vehikel für die schrittweise Erweiterung

genutzt werden

● Pro– funktionale Hierarchien lassen sich (relativ) leicht in eine

Modulstruktur transformieren

● Contra– Entwurf wird leicht als schlechter OO-Entwurf missverstanden

minimal subsetminimal subset

minimal extensionminimal extension

incrementalsystem design

object orientation

base classbase class

derived classderived class

inheritance

[6]


PURE – Größen

preemptionpreemption

synchronizationsynchronizationobjectificationobjectification

dispatchingdispatching

schedulingscheduling

propagationpropagation

interruptioninterruption

preemptive4062

non-preemptive1699

cooperative1648

exclusive434

coordinative2306

interruptive1268

● … durchaus mit denen von OSEK-Systemen vergleichbar– Inlining dank C++ und Inline-Optimierungswerkzeug– kaum virtuelle Funktionen durch den familienbasierten Entwurf


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 oderStoic können Schichtenauch inaktiv sein

● Beherrschbar nur mitWerkzeugunterstützung!


Wiederholung: ProduktlinienentwicklungProblemraumProblemraum LösungsraumLösungsraum

KonkretesProblemKonkretesProblem

KonkreteLösungKonkreteLösung

Domänenexperte f1

f7

f3f2

f6f5f4

Merkmale und Abhängigkeiten

PL-Architekt /Entwickler

Class

Aspect

ClassClass

AspectAspectAspect...

Referenzarchitektur / Merkmalimplemente

Applikationsentwickler

f2

f6...

gewünschteEigenschaften

A C

B

D

tatsächlicheEigenschaften

PrinzipienMethodenWerkzeuge


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


FeaturemodellFeaturemodell

Lösungsraum

Einzelnes Problem Einzelne Lösung

Problemraum

FamilienmodellFamilienmodell

VariantenrealisierungVariantenrealisierungVariantenmodellVariantenmodell

pure::variants

In der Übung werden diese Konzepteebenfalls verwendet. Nur das Werkzeugist ein anderes.

In der Übung werden diese Konzepteebenfalls verwendet. Nur das Werkzeugist ein anderes.

pure::variantspure::variants


● 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

p::v-Featuremodell (1)



Darstellung der Eigenschaftenin Baumstruktur

Icons stellen Gruppenart dar

Kreuze stehen für mehrfache Auswahl:1-3 Messsensoren möglich

Doppelpfeile zeigen Alternativen an:Datentransfer entweder USB oder seriell

Fragezeichen kennzeichnen Optionen: Debugsupport ist möglich aber nicht notwendig


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



● 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

p::v-Familienmodell (1)


Die Icons stellen den Typ des Modellelementsdar. 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 Namensgewählt wird.

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.

p::v-Familienmodell (2)


(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

p::v-Konfigurationsraum (1)


Der Configuration Space „Product Variants“ fasst die

Variantendefinitionen für die Produktezusammen.

Jedes Modell repräsentiert eine Variante

In pure::variants werden Produktvariabilitäten (Featuremodelle) und Lösungsarchitekturen (Familienmodelle) flexibel zu Produktlinienkombiniert. Eine Produktlinie kann aus beliebig vielen Modellen bestehen. Der „ConfigurationSpace“ verwaltet diese Informationen und fasst die Varianten einer Produktlinie zusammen.

Diese Variantenmatrix ermöglicht einen Überblick über Unterschiede und

Gemeinsamkeiten der Produktvarianten

p::v-Konfigurationsraum (2)


(variant description model)

definiert eine Variante aus den Möglichkeiten eines Konfigurationsraums

● enthält – alle gewählten Features– alle durch Anwender spezifizierten Attributwerte

p::v-Variantenbeschreibung (1)


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.

p::v-Variantenbeschreibung (2)


p::v-Modellauswertung



p::v-Variantenerstellung

Durch einen Doppelklick wird zur Problemstelle navigiert.

Die Auswertung eines neuen Variantenmodellsergibt hier 2 vom Anwender zu lösende Probleme.

In den beiden Mehrfachauswahlen wurde nochnichts ausgewählt.


Die Auswahl von mindestens einemFeature (Pressure, LCD) löste das Problem.


p::v-Variantenerstellung


Die Resultatsicht (Result view) stellt die errechnete Lösung in (konfigurierbarer) Form als Baum oder Tabelle dar.

Export über das Kontextmenü möglich.

p::v-Resultatsansicht


Eine Transformationskonfiguration wirdeinem Configuration Space zugeordnet.

Die Module werden in der angegebenen Reihenfolge ausgeführt.

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 dermitgelieferten Module nicht ausreichen.

Mitgelieferte Module erlauben zumBeispiel die Erzeugung variantenspezifischer

Dokumentation direkt aus Microsoft Word Dokumenten.

Die Einbindung externer Werkzeugeist einfach und schnell möglich.

p::v-Variantentransformation


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“

● das Generieren von „Class Aliases“

#ifndef __flag_XXX#define __flag_XXX#define XXX 1#endif // __flag_XXX

#ifndef __flag_XXX#define __flag_XXX#define XXX 1#endif // __flag_XXX

#ifndef __alias_YYY#define __alias_YYY#include "ZZZ.h"typedef ZZZ YYY;#endif // __alias_YYY

#ifndef __alias_YYY#define __alias_YYY#include "ZZZ.h"typedef ZZZ YYY;#endif // __alias_YYY


Inhalt● Wiederholung● Architekturtreiber● Familienbasierter Betriebssystementwurf● Anwendungsgetriebene Produktableitung● Merkmalgetriebene Produktableitung● Zusammenfassung


Zusammenfassung● Familienbasierter Systementwurf

eignet sich für den Bau feingranular konfigurierbarer BS-Produktlinien

– Schichtenarchitektur: Konfigurieren durch Weglassen– Erfordert (zu) viel Weitsicht

● EPOSerweitert den Ansatz der applikationsgetriebenen Produktableitung

– Inflated Interfaces– Statische Anwendungsanalyse

● PUREist 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


Literatur[1] G. Böckle, P. Knauber, K. Pohl, K. Schmid (Hrsg.). Software-

Produktlinien. dpunkt.verlag, ISBN 3-89864-257-7, 2004.[2] pure-systems GmbH. Variantenmanagement mit pure-variants.

Technical White Paper, http://www.pure-systems.com/.[3] pure-systems GmbH. pure::variants Eclipse Plugin.

pure-variants. Manual, http://www.pure-systems.com/.[4] A. N. Habermann, L. Flon, and L. Cooprider. Modularization and

Hierarchy in a Family of Operating Systems. Communications of the ACM, 19(5):266-272, 1976.

[5] D. L. Parnas. Designing Software for Ease of Extension and Contraction. IEEE Transactions on Software Engineering, SE-5(2):128-138, 1979.

[6] W. Schröder-Preikschat. The Logical Design of Parallel Operating Systems. Prentice Hall, ISBN 0-13-183369-3, 1994.

[7] A. A. Fröhlich, Application-Oriented Operating Systems.Sankt Augustin: GMD - ForschungszentrumInformationstechnik, 2001, ISBN 3-88457-400-0.

http://www.pure-systems.com/

http://www.pure-systems.com/

Software ubiquitärer Systeme (SuS) · 17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 10...

Documents

Transcript of Software ubiquitärer Systeme (SuS) · 17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 10...