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

DFS


GPL

TRANSPOSE

BFS DFSDIRECTEDUNDIRECTED WEIGHTED

CONNECTEDCOMPONENTS

STRONGLYCONNECTED C.CYCLE CHECKING

SINGLE -SOURCESHORTEST PATH

SEARCH

ALGORITHMS

EDGES


• 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

eval

print

simplify

plus power

eval

print

plus power

eval

print

(a) (b)

(c)

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

DB

Stat Lock

DB

Wo implementiert man hier dieDurchsatz-Messung?

Wie erstellt man ein Produkt mitStatistiken aber ohne Transaktionen?



Stat Lock

DB

Stat Lock

DB

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

DB

Stat


• 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

Index

Feature Modell

Gewollt: 12 Produkte

Database


Gewollt: 4 ProdukteStat Lock

DB

DB

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


Ü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

22

2

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

Undo

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?

121

1

1max --=÷÷

ø

öççè

æ-

=å-

=

non

h nn

o


• Fast aller Quelltext wird in neue Module extrahiert

• 6 Features à 15 Module

Herauslösen im Expression-Problem

eval

print

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

API

get put delete

API

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

Documents

Grundlagen der Softwareproduktlinien: 10. Interaktionen