Post on 15-Nov-2019
11
BetriebssystemtechnikOperating System Engineering (OSE)
Trennung der Belangebei der statischen
Konfigurierung
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 22
Ergebnis der Problemanalyse
(siehe eCos Fallstudie)
Klassische Umsetzung der Konfigurierungsentscheidungen in den Komponenten mit Hilfe von #ifdef und Makros
Schutz vor ungewollten Ersetzungen nur durch strikte Namenskonvention
mangelnde Trennung der Belange
viel Konfigurierungswissen ist im Quellcode verankert
quer schneidende Belange blähen die Funktionen auf
bedingte Übersetzung macht den Code schwer verständlich, zu warten und wiederzuverwenden
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 33
Lösungsansätze
(durch statische Konfigurierungswerkzeuge)
Frame Prozessoren – z.B. XVCL [3]
Quellcode ist nur ein „Rahmen“, der je nach Konfiguration mit zusätzlichem Code angereichert werden kann
Ansatz ist unabhängig von der Programmiersprache
- selbst Dokumentation lässt sich damit konfigurieren
Variantenmanagement – z.B. pure::variants [1, 2] zusätzliche (programmierbare) Ebene oberhalb der Komponenten
flexible Generierungs- und Transformationsmöglichkeiten
automatisierte Abbildung von Anforderungen (z.B. Merkmalselektion) auf Softwarevarianten
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 44
XVCL – ein Frame Prozessor
XML-based Variant Configuration Language
Was ist ein frame?
XVCL arbeitet mit frames in Form von Textdateien
„When one encounters a new situation (or makes a substantial change in one's view of a problem) one
selects from memory a structure called a frame. This is a remembered framework to be adapted to fit
reality by changing details as necessary.“
M. MinskyA Framework for Representing Knowledge
1975
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 55
XVCL – Grundbegriffe
x-frame
x-frame x-frame
x-frame x-frame x-frame
x-framework
Kompositionund
Anpassung
XVCL Prozessor
SPC
Specification x-frame
component component
component
angepassteKomponenten
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 66
XVCL – Grundbegriffe
x-frame
x-frame x-frame
x-frame x-frame x-frame
x-framework
Kompositionund
Anpassung
XVCL Prozessor
SPC
Specification x-frame
component component
component
angepassteKomponenten
Lösungsraum einzelnesProblem
einzelneLösung
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 77
XVCL – Verarbeitung (1)
<x-frame name=“A“> AAA before <adapt x-frame=“B“/> AAA <adapt x-frame=“C“/> AAA after</x-frame>
<x-frame name=“B“> BBB before <adapt x-frame=“D“/> BBB <adapt x-frame=“E“/> BBB after</x-frame>
<x-frame name=“C“> CCC before <adapt x-frame=“E“/> CCC <adapt x-frame=“F“/> CCC after </x-frame>
<x-frame name=“E“> EEE</x-frame>
<x-frame name=“D“> DDD</x-frame>
<x-frame name=“F“> FFF</x-frame>
x-frames bestehen aus• XML Tags• beliebigem Text
mittels adapt kann einweiterer frame verarbeitetwerden
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 88
XVCL – Verarbeitung (2)
<x-frame name=“A“> AAA before <adapt x-frame=“B“/> AAA <adapt x-frame=“C“/> AAA after</x-frame>
<x-frame name=“B“> BBB before <adapt x-frame=“D“/> BBB <adapt x-frame=“E“/> BBB after</x-frame>
<x-frame name=“C“> CCC before <adapt x-frame=“E“/> CCC <adapt x-frame=“F“/> CCC after </x-frame>
<x-frame name=“E“> EEE</x-frame>
<x-frame name=“D“> DDD</x-frame>
<x-frame name=“F“> FFF</x-frame>
1
2
3
4
6
511
12
10
8
7
13
9
Ausgabe:
AAA beforeBBB beforeDDDBBBEEEBBB afterAAACCC beforeEEECCCFFFCCC afterAAA after
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 99
XVCL – Dateiselektion
<x-frame name=“A“ outfile=“A.cc“> AAA before <adapt x-frame=“B“/> AAA <adapt x-frame=“C“/> AAA after</x-frame>
<x-frame name=“B“> BBB</x-frame>
<x-frame name=“C“ outfile=“C.h“> CCC </x-frame>
A.cc:
AAA beforeBBBAAAAAA after
C.h:
CCC
normalerweise wirkt adapt wie #include
Komposition aus (angepassten) Codefragmenten
in Verbindung mit outfile kann der SPCbestimmen, welche Dateien generiert werden
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 1010
XVCL – Anpassung von Frames (1)<x-frame name=“A“ outfile=“A.cc“> <adapt x-frame=“C“> <insert break=“HEADER“> --inserted-- </insert> <insert break=“FOOTER“> <adapt x-frame=“B“/> </insert> </adapt></x-frame>
<x-frame name=“C“ outfile=“C.h“> <break name=“HEADER“/> CCC <break name=“FOOTER“/> </x-frame>
C.h:
--inserted--CCCBBB
<x-frame name=“B“> BBB</x-frame>
durch break und insert (-before, -after) kann an vordefinierten Stellen durch übergeordnete Frames Text eingefügt werden
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 1111
XVCL – Anpassung von Frames (2)
<x-frame name=“A“ outfile=“A.cc“><set-multi var="NAME" value="a,b"/><set var="VAL_a" value="4711"/><set var="VAL_b" value="815"/><while using-items-in="NAME"> <set var="VAL" value="?@VAL_@NAME?"/> <adapt x-frame="C"/></while></x-frame>
<x-frame name=“C“ outfile=“C.h“><value-of expr="?@NAME?"/>=<value-of expr="?@VAL?"/></x-frame>
C.h:
a=4711b=815
Variablen, Schleifen und Bedingungen erlauben flexible Textgenerierung
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 1212
XVCL – Beispiel I/O-Library (1)
die OStream Klasse enthält lediglich das Grundgerüst und Markierungen an potentiellen Variationspunkten
<x-frame name="OStream">#ifndef __OStream_h__#define __OStream_h__
#include "OStreamDock.h"<break name="STREAM_INCLUDE"/>
class OStream : public OStreamDock {<break name="STREAM_ATTRIBUTE"/>public: OStream& operator << (char) {...} OStream& operator << (OStream& (*f) (OStream&));<break name="STREAM_OP"/>};
OStream& endl (OStream& os) {...}<break name="STREAM_MANIP"/>
#endif // __OStream_h__</x-frame>
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 1313
XVCL – Beispiel I/O-Library (2)
getrennte x-frames beschreiben die Erweiterungen für die verschiedenen unterstützten Datentypen (slices)
<x-frame name="IntegerOStream"> <select option="SECTION"> <option value="INCLUDE"> #include "IntegerOutput.h" </option> <option value="ATTRIBUTE"> IntegerOutput iout; </option> <option value="OP"> OStream & operator << (MaxInt i) { ... } </option> </select></x-frame>
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 1414
<x-frame name="IntegerOStream"> <select option="SECTION"> <option value="INCLUDE"> #include "IntegerOutput.h" </option> <option value="ATTRIBUTE"> IntegerOutput iout; </option> <option value="OP"> OStream & operator << (MaxInt i) { ... } </option> </select></x-frame>
XVCL – Beispiel I/O-Library (2)
getrennte x-frames beschreiben die Erweiterungen für die verschiedenen unterstützten Datentypen (slices)
<x-frame name="PointerOStream"> <select option="SECTION"> <option value="INCLUDE"> #include "PointerOutput.h" </option> <option value="OP"> OStream & operator << (void *p) { ... } </option> </select></x-frame>
...
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 1515
XVCL – Beispiel I/O-Library (3)
ein weiterer x-frame fügt die OStream Klasse entsprechend der konfigurierten Typen in TYPES zusammen
<x-frame name="ConfigOStream" outfile="OStream.h"> <adapt x-frame="OStream"> <insert break="STREAM_INCLUDE"> <set var="SECTION" value="INCLUDE"/> <while using-items-in="TYPES"> <adapt x-frame="?@TYPES?"/> </while> </insert> <insert break="STREAM_ATTRIBUTE"> <set var="SECTION" value="ATTRIBUTE"/> <while using-items-in="TYPES"> <adapt x-frame="?@TYPES?"/> </while> </insert> ... weitere inserts für Operationen und Manipulatoren </adapt></x-frame>
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 1616
XVCL – Beispiel I/O-Library (4)
der SPC beschreibt eine konkrete Konfiguration in kompakter Weise
<x-frame name="Test1"> <set-multi var="TYPES" value="IntegerOStream,PointerOStream"/> <adapt x-frame="ConfigOStream"/></x-frame>
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 1717
XVCL - Zusammenfassung
Pro Konfigurationswissen und Programmcode kann getrennt werden
selektives Generieren von Dateien möglich
Quellcodeorganisation kann unabhängig von Modularisierungs-techniken der Programmiersprache (z.B. Klassen) erfolgen
programmiersprachenunabhängiger Ansatz
Contra XML Syntax und Escape-Zeichen im Quelltext, z.B. &
fehlende Verbindung zwischen XVCL Quelltext und generiertem Quelltext problematisch bei Fehlermeldungen des Übersetzers
keine explizite Repräsentation des Problemraums
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 1818
Domänenexperte
Lösungsraum
Einzelnes Problem Einzelne Lösung
ProblemraumPL Architekt / PL Entwickler
ApplikationsentwicklerApplikationsanalyst
Rollenverteilung bei der PL-Entwicklung
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 1919
Eigenschaften und Abhängigkeiten
Lösungsraum
Einzelnes Problem Einzelne Lösung
ProblemraumAuswahl der Software-Elemente
Ressourceneffizienzgewünschte Eigenschaften
Technische Herausforderung
BeschreibungRealisierung
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 2020
Featuremodell
Lösungsraum
Einzelnes Problem Einzelne Lösung
ProblemraumFamilienmodell
VariantenrealisierungVariantenmodell
Variantenmanagement mit p::v
pure::variants
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 2121
Alle Modelle besitzen gleiche Grundstruktur
Element ist Grundbaustein
Elemente können gerichtete Beziehungen zu anderen Elemente haben (Relationen)
Elemente können Attribute besitzen
An vielen Modellbestandteilen können Restriktionen die Gültigkeit einschränken
Speicherung im XML-Format
p::v Modellgrundstruktur
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 2222
Jedes Element gehört zu einer Klasse: ps:feature, ps:component, ps:part, ps:source
Jedes Element hat einen Typ, z.B. ps:file
Typsystem ist frei konfigurierbar, p::v benutzt fast immer nur die Elementklassen
Ausnahme: Standardtransformation
Standardinformationen
ID, Unique Name, Visible Name, Beschreibung
Optional: Relationen, Restriktionen
p::v Element
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 2323
Elementrelationen sind „1:n“ Verbindungen
Relationen werden immer im Ausgangselement gespeichert
Relationen besitzen einen Typ
p::v definiert einige Relationen wie z.B. „ps:requires“ (und deren Semantik)
Benutzer kann eigene Relationstypen einführen
Jede Relation kann eine Beschreibung besitzen
Eine Relation kann Restriktionen besitzen
Relation ist nur gültig, wenn Restriktion „wahr“ liefert
p::v Elementrelationen
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 2424
Jedem Element kann eine beliebige Anzahl von Attributen zugeordnet sein.
Ein Attribut ... ist getypt (ps:string, ps:boolean, ...)
hat einen Namen
kann Restriktionen besitzen
Der Attributwert ... kann im Modell festgelegt werden (fixed)
kann in der Variantenbeschreibung gesetzt werden (not fixed)
Beispiel: Merkmal Motor (Attribut, Wert)1 = („Leistung [kW]“, 85)
(Attribut, Wert)2 = („Zylinder“, 4)
p::v Elementattribute (1)
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 2525
Attributwerte
Konstante
Berechnung (calculation)
Jede Wertdefinition kann eine Restriktion besitzen
Reihenfolge der Werte ergibt Berechnungsfolge
Erste gültige Wertdefinition bestimmt Attributwert
Ein Attribut eines ausgewählten Elements muss einen gültigen Wert haben
„Not fixed“ Attribute können eine Defaultwertdefinition besitzen
p::v Elementattribute (2)
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 2626
Eine Restriktion schränkt die Gültigkeit/Verwendbarkeit des zugeordneten Bestandteils ein
p::v verwendet eine an OCL angelehnte Notation, die von pvProlog ausgewertet wird
Die genaue Semantik wird durch die Art des Bestandteils bestimmt
Beispiel:
hasFeature('A') or not(hasFeature('B'))
p::v Restriktionen
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 2727
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)
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 2828
p::v Featuremodell (2)
Darstellung der Eigenschaftenin 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
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 2929
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)
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 3030
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)
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 3131
Die Icons stellen den Typ des Modellelementsdar. Hier eine Komponente. Diese Typen sindfrei 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)
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 3232
(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)
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 3333
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)
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 3434
(variant description model)
definiert eine Variante aus den Möglichkeiten eines Konfigurationsraums
enthält alle gewählten Features alle durch Anwender spezifizierten Attributewerte
p::v Variantenbeschreibung (1)
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 3535
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)
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 3636
p::v Modellauswertung
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 3737
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.
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 3838
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
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 3939
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
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 4040
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
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 4141
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 __alias_YYY#define __alias_YYY#include “ZZZ.h“typedef ZZZ YYY;#endif // __alias_YYY
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 4242
pure::variants - Zusammenfassung
p::v ist ein als Eclipse-Plugin realisiertes kommerzielles Werkzeug zum Variantenmanagement
p::v 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
zur Auswertung von Attributen, Relationen und Restriktionen steht dem Entwickler die volle Leistungsfähigkeit von Prolog zur Verfügung
die Generierung der Lösung basiert auf einer einfachen „Standardtransformation“, die aber erweitert und um weitere Transformationen ergänzt werden kann
pure::variants erlaubt das automatische Generierenvon Applikationen anhand von Merkmalselektionen.
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 4343
Ausblick
Untersuchung verschiedener Techniken zur Umsetzung von Variabilität in der Implementierung der Komponenten
programmiersprachenbasierte Lösungen
- Aspekte
- Objekte
- Templates
- Mixin Layers
© 2007, 2008 Wolfgang Schröder-Preikschat, Olaf Spinczyk 4444
Literatur
[1] pure-systems GmbH. Variantenmanagement mitpure-variants. Technical White Paper,http://www.pure-systems.com/.
[2] pure-systems GmbH. pure::variants Eclipse Plugin.pure-variants. Manual, http://www.pure-systems.com/.
[3] National University of Singapore. XML-based VariantConfiguration Language (XVCL). 2004.