software ubiquitärer systeme (sus) · 17.05.2017 sus: 03.4 betriebssystem-produktlinien 10...
TRANSCRIPT
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
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 3
Inhalt● Wiederholung● Architekturtreiber● Familienbasierter Betriebssystementwurf● EPOS: Anwendungsgetriebene Produktableitung● PURE: Merkmalgetriebene Produktableitung● Zusammenfassung
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 4
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 5
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 6
Inhalt● Wiederholung● Architekturtreiber● Familienbasierter Betriebssystementwurf● EPOS: Anwendungsgetriebene Produktableitung● PURE: Merkmalgetriebene Produktableitung● Zusammenfassung
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 8
Inhalt● Wiederholung● Architekturtreiber● Familienbasierter Betriebssystementwurf● EPOS: Anwendungsgetriebene Produktableitung● PURE: Merkmalgetriebene Produktableitung● Zusammenfassung
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 9
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 10
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 11
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 12
Funktionale Hierarchie – Elemente
1
2
3
4
disk accessdisk access
irq monitorirq monitorclock driverclock driver disk driverdisk driver
process managerprocess manager file systemfile system
...
process schedulerprocess scheduler
Funktionen elementare Systembausteine der Software (Entwurfsebene) „logische Funktionen“
Funktionen elementare Systembausteine der Software (Entwurfsebene) „logische Funktionen“
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 13
Funktionale Hierarchie – Elemente
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 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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 14
Funktionale Hierarchie – Elemente
1
2
3
4
disk accessdisk access
irq monitorirq monitorclock driverclock driver disk driverdisk driver
process managerprocess manager file systemfile system
...
process schedulerprocess scheduler
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 15
● 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
disk accessdisk access
irq monitorirq monitorclock driverclock driver disk driverdisk driver
process managerprocess manager file systemfile system
process schedulerprocess scheduler
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 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]
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 18
Inhalt● Wiederholung● Architekturtreiber● Familienbasierter Betriebssystementwurf● EPOS: Anwendungsgetriebene Produktableitung● PURE: Merkmalgetriebene Produktableitung● Zusammenfassung
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 20
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 21
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 22
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 23
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;
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 24
EPOS – Anforderungsanalyse (3)
flat memorylinks
syntacticanalyzer
real application program (MPI)
Channel link(destination);link << message;
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 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
reduziertexecution scenario
+ =tasks
segments
threadsmailboxes
monitorsfiles
required Inflated interfaces
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 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 EPOSauf generischer und generativerProgrammierung in C++
application
interfaces
scenario adapters
system micro-components
system abstractions
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 27
Inhalt● Wiederholung● Architekturtreiber● Familienbasierter Betriebssystementwurf● EPOS: Anwendungsgetriebene Produktableitung● PURE: Merkmalgetriebene Produktableitung● Zusammenfassung
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 28
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 29
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]
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 30
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 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 oderStoic können Schichtenauch inaktiv sein
● Beherrschbar nur mitWerkzeugunterstützung!
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 32
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 34
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 35
● 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)
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 36
p::v-Featuremodell (2)
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 37
● 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)
p::v-Featuremodell (3)
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 38
● 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)
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 39
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)
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 40
(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)
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 41
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)
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 42
(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)
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 43
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)
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 45
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-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.
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 46
Die Auswahl von mindestens einemFeature (Pressure, LCD) löste das Problem.
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-Variantenerstellung
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 47
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 48
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 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“
● 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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 50
Inhalt● Wiederholung● Architekturtreiber● Familienbasierter Betriebssystementwurf● Anwendungsgetriebene Produktableitung● Merkmalgetriebene Produktableitung● Zusammenfassung
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 51
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
17.05.2017 SuS: 03.4 Betriebssystem-Produktlinien 52
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.