grundlagen der softwareproduktlinien: 10. interaktionen

109.01.20Gunter Saake, Jacob Krüger | Einführung in Softwareproduktlinien

Grundlagen der Softwareproduktlinien: 10. Interaktionen

Wintersemester 2019/20Gunter Saake

Feature-Interaktionen

• Telefonproduktlinie: Manche Telefone unterstützen „Anklopfen“, andere „Rufumleitung bei Besetzt“

• Was passiert wenn beide Features aktiviert sind?• Freie Leitung: kein Problem• Besetzte Leitung: anklopfen oder umleiten?

• Kann man solche Probleme erkennen?

Beispiel: Feature-Interaktionen

• Flood Control• Verhindert Überschwemmung durch Wasser abstellen

• Fire Control• Bekämpft Feuer mit Sprinkleranlage

Beispiel: Feature-Interaktionen

• Cycle braucht DFS• Shortest Path geht nur auf gewichteten Graphen• Connected geht nur auf ungerichteten Graphen• Strongly Connected geht nur auf gerichteten Graphen und braucht

TRANSPOSE

BFS DFSDIRECTEDUNDIRECTED WEIGHTED

CONNECTEDCOMPONENTS

STRONGLYCONNECTED C.CYCLE CHECKING

SINGLE -SOURCESHORTEST PATH

SEARCH

ALGORITHMS

• Datenbank-Produktlinie mit Feature • Statistics• Transactions

• Statistics sammelt Statistiken über Buffer Hit Ratio, Tabellen-Größe, Transaktionen

• Transaktionen stellt ACID-Eigenschaften sicher

• Beide Features sollen optional sein• Aber: Statistik sammelt Informationen über Transaktionen,

Transaktionen nutzen evtl. statistische Informationen ...

• Wie implementieren, so dass alle Varianten möglich sind?

Database

Statistics Transactions

• Datenbank-Produktlinie mit Feature Index und Update• Index: Beschleunigt den Zugriff durch B-Baum• Update: Erlaubt Updates der Datenbank, sonst nur Lesezugriff

• Beide Features sollen optional sein• Effizienter Leseindex• Schreiben in Datenbank ohne Index• Aber: Wenn beide Features � schreiben auch in Index

• Wie implementieren, so dass alle Varianten möglich sind?

lnplus power

simplify

plus power

(a) (b)

Daten-zentriert Methoden-zentriert (Visitor)

AOP & FOP

• Features benutzen Methoden anderer Features• Cycle nutzt die Suchfunktion Graph.search, die in DFS

eingeführt wurde• Shorted Path erwartet, dass die Methode Edge.getWeight

vorhanden ist

• Features erweitern andere Features• Feature Weighted implementiert Gewichte indem es Methode

addEdge aus Base überschreibt

• Features verlassen sich auf ein bestimmtes Verhalten, welches in einem Feature festgelegt wird

• Connected erwartet das Kanten immer in beide Richtungen zeigen

Interaktion verursacht Abhängigkeiten

• Optionales Feature verhält sich isoliert korrekt

• Problem in Kombination mit anderem Feature

• Zusätzlicher Quelltext koordiniert richtiges Verhalten

Probleme optionaler Features

Transaktionen Statistiken

Statistiken über Transaktionen

Anklopfen Rufumleitung

Einstellungsmöglichkeit

Add Eval

Auswerten von Add

+Index Update

Schreiben in Index+

Probleme optionaler Features

Statistiken(buffer hit ratio, table size and cardinality, …)

Transaktionen(locks, commit,rollback, …)

Durchsatz-Messung(“Transaktionen pro Sekunde”)

Erwünschte Produkte

Datenbank mit Statistiken, aber ohne Transakt.

Datenbank mit Transakt., aber ohne Statistiken

Datenbank mit Statistikenund mit Transaktionen

Requirements Engineering II - SPL: Feature-Interaktionen

Unerwünschte/Unmögliche Produkte

Datenbank mit Transaktionen und ohneStatistiken, die aber denoch den Durchsatz misst(Grösser und langsamer als nötig)

Datenbank mit Statistiken und ohneTransaktionen, die dennoch denDurchsatz misst (?)

Implementierungsbeispiel

• Sperren (blau)

• Statistiken (rot)

• Die Features überlappensich an 2 Stellen (violett)• Statistiken über Locks• Synchronisierung der

Statistikmethode

class Database {List locks;void lock() { /*...*/}void unlock() { /*...*/ }void put(Object key,Object data){

lock(); /*...*/unlock();

}Object get(Object key) {

lock(); /*...*/ unlock();

}int getOpenLocks() {

return locks.size(); }int getDbSize() {

return calculateDbSize(); }static int calculateDbSize() {

lock();/*...*/ unlock();

Aufteilung in Module?

Stat Lock

DBWo implementiert man hier die

Durchsatz-Messung?

Stat Lock

Wo implementiert man hier dieDurchsatz-Messung?

Wie erstellt man ein Produkt mitStatistiken aber ohne Transaktionen?

Stat Lock

Database

Txn-Stats

Wo implementiert man hier dieDurchsatz-Messung?

Wie erstellt man ein Produkt mitStatistiken aber ohne Transaktionen?

Ist Durchsatz-Messungwirklich ein Feature? LockStat Lock

• Beschreibt wie viele Produkte aus einer Produktlinie erstellt werden können

• Eine Produktlinie mit n unabhängigen, optionalen Features erlaubt 2n Produkte

• Abhängigkeiten zwischen Features schränken die Variabilität der Produktlinie ein

• Eine einzige Abhängigkeit „Feature A benötigt B“ reduziert die Anzahl der möglichen Produkte um 25%

Variabilität

Eingeschränkte Variabilität

EingeschränkteVariabilität

Mapping

Database

Statistics TransactionsAccess

Read Write

Feature Modell

Gewollt: 12 Produkte

Database

Gewollt: 4 ProdukteStat Lock

Stat LockWrtIdx

Tatsächlich möglich: 5 Produkte

Tatsächlich möglich: 3 Produkte

Implementierung

Mapping

• „A benötigt B“, „B benötigt C“ à „A benötigt B und C“

• Folge: Einzelne Features können die Auswahl vieler weiterer Features erzwingen und die Variabilität der SPL deutlich einschränken

• Beispiel: Berkeley DB• Das Statistik-Feature sammelt Statistiken über verschiedene

Bereiche des Programms, z.B. Speicherverbrauch, Transaktionen, Schreibzugriffe, Buffer Hit Ratio, usw.

• Die Auswahl des Statistik-Features erzwingt die Auswahl von 14 (von 37) weiteren Features, u. a. Transaktionen, Caches

Abhängigkeiten sind transitiv

Auflösung von Feature-Interaktionen

• Dynamisch vs. Statisch• Dynamisch: Beim Ausführen einer Variante; unerwartetes

Verhalten, Abstürze, Race Conditions• Statisch: beim Generieren/Kompilieren einer Variante; z. B.

Methode aufgerufen, die nicht definiert ist

• Domäne vs. Implementierung• Domänenabhängigkeit: Die Abhängigkeit ist durch die Domäne

konzeptionell festgelegt; alternative Implementierungen haben die gleichen Abhängigkeiten

• Implementierungsabhängigkeit: Abhängigkeit entsteht durch eine gewählte Implementierung; alternative Implementierung ist möglich

Klassifikation

• Schwer zu erkennen

• Viel Forschung in Telekommunikationssystemen• M. Calder, M. Kolberg, E.H. Magill, S. Reiff-Marganiec. Feature

interaction: A critical review and considered forecast. Computer Networks, Volume 41, Issue 1, 2003, pp. 115-141

• Bei Anforderungsanalyse durch spezielle Modellierung gezielt nach Interaktionen suchen

• Formale Spezifikation, Model Checking, …

• Testen, testen, testen ...

• Wenn gefunden à Problem optionaler Features

Dynamische Feature-Interaktionen

• Implementierungsabhängigkeiten sind unangenehm

• Reduzierte Variabilität, obwohl Varianten in Domäne möglich wären

• Beispiel: Transaktionen vs. Statistiken (s.o.)• Lösung 1: im Feature-Modell benötigt Statistik Transaktionen à

Reduzierte Variabilität• Lösung 2: Keine Statistik über Transaktionen à schlechtere

Implementierung

• Daher gesucht: Möglichkeit Implementierungs-abhängigkeiten aufzulösen

Implementierungsabhängigkeiten

• Wie modularisiert man zwei interagierende Features?

• Ziele:• Variabilität wie im Feature-Modell vorgesehen• Geringer Implementierungsaufwand• Effiziente Implementierung (Codegröße, Performance)• Code Qualität (Trennung v. Belangen, Modularität)

Lösungen (L) für Probleme

Modul-Schnittstelle

L 1: Mehrere Implementierungen

Variability Impl. Effort Binary Size & Perf. Code Quality

Produkte

L 1: Mehrere Implementierungen

Code Replikation

Produkte

L 2: Abhängigkeiten in Feature-Modell

Produkte

L 2: Abhängigkeiten in Feature-Modell

Produkte

Varianten nicht

möglich

L 3: Quelltext verschieben

Produkte

L 3: Quelltext verschieben

Nicht effizient

Produkte

L 4: Verhalten ändern

Produkte

L 4: Verhalten ändern

Produkte

Fehlendes

Verhalten

L 5: Präprozessor

#ifdef TXNlock();#ifdef STATlockCount++;#endif#endif

Produkte

L 5: Präprozessor

nicht modular

#ifdef TXNlock();#ifdef STATlockCount++;#endif#endif

Produkte

L 6: Herauslösen der Interaktionen

Produkte

L 6: Herauslösen der Interaktionen

Zusätzl. Modul

(aufwändig)

Produkte

Überblick

Keine beste Lösung

Beispiel: Herauslösen von Interaktionen

• Feature Modul enthält nur den eigenen Code, keinen Interaktionscode

• Neues Modul (A\B) wird immer (automatisch) ausgewählt wenn A und B ausgewählt sind

• A\B erweitert A oder B wenn beide ausgewählt

• Damit sind alle 4 Konfigurationen möglich• ohne A, ohne B• mit A, ohne B• ohne A, mit B• mit A, mit B (und mit A\B)

• „Optimale“ Implementierung für alle Varianten

Herauslösen

• Manuelles Herauslösen sehr aufwendig

• Zusätzliche Module à höhere Komplexität

• Interaktionen sind oft stark verteilte, heterogene Erweiterungen

• Theoretisch sehr viele binäre Interaktionen möglich

• Auch Interaktionen zwischen mehr als zwei Features möglich

Probleme

maxnnn

i -=÷÷

öççè

Interaktionen höherer Ordnung

Beispiel

class Stack {boolean push(Object o) {

Lock lock=lock();if (lock==null) {

log("lock failed for: "+o)’;return false;

}rememberValue ();elementData[size ++] = o;...}

void log(String msg) { /*...*/ }

boolean undo () {Lock lock=lock();if (lock==null) {

log("undo-lock failed")’;return false;

}restoreValue ();...log("undone.")’;

Beispiel

class Stack {boolean push(Object o) {

Lock lock=lock();if (lock==null) {

log("lock failed for: "+o)’;return false;

}rememberValue ();elementData[size ++] = o;...}

void log(String msg) { /*...*/ }

boolean undo () {Lock lock=lock();if (lock==null) {

log("undo-lock failed")’;return false;

}restoreValue ();...log("undone.")’;

Locking-Logging

Logging

Locking

UndoUndo-Locking

Undo-Locking-Logging

Undo-Logging

• Theoretisch möglich (mit höherer Ordnung):

• Tatsächliche Anzahl• Deutlich geringer• Aber trotzdem häufig mehr als Features im System

Wieviele Interaktionen möglich?

1max --=÷÷

öççè

• Fast aller Quelltext wird in neue Module extrahiert

• 6 Features à 15 Module

Herauslösen im Expression-Problem

simplify

lnplus power

Erfahrungen und Praxis

• Abhängigkeiten beibehalten?

• Verhalten ändern?

• Herauslösen der Interaktion?

• Präprozessor?

Berkeley DB

• Abhängigkeiten beibehalten?• Wichtige Features waren de-facto obligatorisch (Statistiken,

Transaktionen, Speicherverwaltung, …)

• Verhalten ändern?• Wir wollten das bestehende Verhalten beibehalten

• Herauslösen der Interaktion?• 76% des Statistikcodes in 9 Module extrahiert• Möglich, aber aufwendig

• Präprozessor?• Viel schneller, einfacher• Deutlich verstreute und vermischte Belange

Berkeley DB

• Feature Modell ändern• Vermeidet 14 Abh. und verhindert ¾ der Produkte

• Logging mit Präprozessor• Vermeidet 11 Abh., aber verstreuter Quelltext

• B-Baum kann immer geschrieben werden• Anstieg der Binärgöße um 5—13%

• 10 verbleibende Interaktionen herausgelöst

FAME-DBMS

get put delete

Read Write

• Variabilität ist kein Selbstzweck• Mit 33 optionalen unabhängigen Features kann man eine

Variante für jeden Menschen auf dem Planeten erstellen• Mit 320 Features eine Variante für jedes Atom im Universum• Niemand kann all diese Varianten testen; niemand braucht all

diese Varianten

• Daher• Konzentration auf benötigte Varianten• Variabilitätsmanagement, Variabilität an der richtigen Stelle,

Domänenanalyse

Welche Interaktionen auflösen?

Exkurs: PKW-Produktlinie

• Auswahl beschränkte sich auf Autotyp und ggf. noch wenige Extras wie alternativer Kassettenrekorder oder Dachgepäckträger

• Eine Variante (Audi 80, 1.3l, 55PS) machte 40% des Umsatzes aus

Vor 20 Jahre

• 1020 mögliche Varianten eines Audi; 1032 mögliche Varianten eines BMW

• Kaum ein Auto verlässt das Werk identisch zu einem vorherigen

• Allein 100 verschiedene Bodengruppen für ein Modell, je nach Motor und Ausstattung

• 50 verschiedene Lenkräder (3 vs. 4 Speichen, Holz vs. Kunststoff vs. Leder, Heizung, Farben)

Vor einigen Jahren

• Hohe Variantenzahl verursacht enorme Kosten und Komplexität• Hohe Logistikkosten• Entwicklungsaufwand• Investitionen für Werkzeuge und Anlagen• Hohe Fertigungskosten aufgrund geringer Stückzahlen,

besonders bei zugekauften Teilen

• „Wir brauchen aber genügend Varianten, um die Kundenwünsche zu erfüllen.“

• Lösungsansatz: Variantenmanagement als strategisches Projekt; beteiligt Entwickler, Logistiker und Marketing

Probleme der Produktlinie

• Zuerst Analyse, was überhaupt und in welcher Kombination nachgefragt wird

• Exotische Varianten werden gestrichen• „Es sollte nicht sein, dass wir Teile entwickeln und herstellen,

die wir dann nicht verbauen“

Variantenmanagement

• Zuerst Analyse, was überhaupt und in welcher Kombination nachgefragt wird

• Exotische Varianten werden gestrichen• „Es sollte nicht sein, dass wir Teile entwickeln und herstellen,

die wir dann nicht verbauen“

• Variantenmanagement wird möglichst früh eingesetzt, schon bei der Entwicklung

• Audi konnte 5 Millionen Euro durch Variantenreduktion des Dachmoduls einsparen, indem das zentrale Bedienelement neutral gestaltet wurde, so dass es zu allen Dachhimmeln passt

• BMW hat die Anzahl der Bodengruppen von 100 auf 4 reduziert: Rechts-/Linkslenker, mit/ohne Schiebedach; für Kunden waren Unterschiede zuvor eh nicht sichtbar.

Variantenmanagement

• Nötige Variabilität bieten• Unnötige Variabilität vermeiden• Reduziert Entwicklungskosten• Reduziert Testkosten• Reduziert Wartungskosten

• z. B. Shorted Path von Weighted entkoppeln, wenn es Bedarf dafür gibt, sonst Abhängigkeit belassen

• z. B. Statistiken und Transaktionen nur mit Glue-Code trennen falls Bedarf erkennbar

In Softwareproduktlinien

Zusammenfassung

• Vergleich von FOP und AOP

• Symbiose von FOP und AOP

• Feature-Interaktionen• Probleme• Lösungsansätze

• Variantemanagement

Zusammenfassung

Fragen

grundlagen der softwareproduktlinien: 10. interaktionen

Documents

interaktionen der dialkylether mit humanen...

strukturelemente sozialer interaktionen - e-lib · dominic...

interaktionen machen marken. oder wie die digitalisierung...

funktionelle interaktionen von tau mit anderen proteinen...

interaktionen des humanpathogenen schimmelpilzes ·...

interaktionen von rnas und proteinen - uni-leipzig.de ·...

unterstützung von videobasiertem unterricht durch...

modulhandbuch - uni-wuerzburg.de · grundlagen 1 -...

grundlagen der softwareproduktlinien: 4. laufzeitparameter...

symbiotische interaktionen mit freundlichen ... ·...

informationen zu nebenwirkungen und interaktionen von ... -...

untersuchungen zu frühen erreger-wirts- interaktionen bei

grundlagen fb kunst // künstlerische grundlagen ... ·...

softwareproduktlinien - dbse.ovgu.de · stand 2005 (i) 5...

grundlagen der softwareproduktlinien: 3. feature...

softwareproduktlinien - ain't nobody got time for that? ·...

detektion von protein/protein-interaktionen mit hilfe...

softwareproduktlinien-entwicklung – domain engineering...

grundlagen haushaltsfÜhrungkommunaler - hss...grundlagen...

tagungsinformationen & ehealth in interaktionen … ·...