Lehrstuhl Praktische Informatik Wiederverwendung von Softwarepi.informatik.uni-siegen.de/lehre/Vertiefungspraktika/2017s/materials/slides/2017s_PEP... · • Im Prinzip gibt es beliebige

Lehrstuhl Praktische Informatik

Wiederverwendung

von Software

Dennis Reuling

[email protected]


WIEDERVERWENDUNG

Wiederverwendung von Software 2

• Produkte möglichst weitgehend aus vorhandenen / vorgefertigten Standard-Komponenten konstruieren

Vorteile:

– Kostensenkung, weniger Neuentwicklung

– Erhöhung der Qualität

Keine neue Idee, passiert tausendfach:

– Benutzung von Bibliotheken

– Muster, ...


Grundidee

Nach Größe der Artefakte sortiert:1. Programmstrukturen, Konzepte der

Programmiersprache

2. Entwurfsmuster, Analysemuster

3. Architekturmuster

4. Standardarchitekturen

Sind Gestaltungsregeln, d.h. keine Komponenten, die man i.w. unverändert einbaut

überlappt thematisch mit Wiederverwendung


WV vs Regeln/Erfahrung

• Fremdherstellung von Komponenten ist in

klassischen Industrien üblich:

– ggf. eigenes, umfangreiches Know-How

(Domänenwissen) erforderlich, das nicht zu

den Kernkompetenzen des Anbieters gehört

– Ausnutzung von Skaleneffekten bei kleinen

Produktionsmengen


WV vs Arbeitsteilung (1)

• Allgemeines Prinzip der industriellen

Arbeitsteilung:

– spezialisierte Marktteilnehmer

– geringe Fertigungstiefe

– Konzentration auf Kernkompetenzen

• Wichtig:

– nicht zu viele Modelle, Normen

– Keine offene Spezifikationen



• Besonderheiten in der Informatik:– Größe der Produktionsmengen irrelevant für SW-

Produkte

– „Versteckte” technologische Arbeitsteilung durch Benutzung von:

• Netzwerkprotokollen

• mathematische Bibliotheken

• …

Technologische Arbeitsteilung in der Informatik selbstverständlich

• Ist auch ohne Wiederverwendung sinnvoll (zugekaufte Komponenten werden nur 1* verwendet)



• Wiederverwendung:

– Fälle, wo mehrere einander ähnliche Systeme in

der gleichen Technologie entwickelt werden:

• ggf. in verschiedenen Zeiträumen

• insb. bei Systemen, die nicht Varianten voneinander

sind, sondern unabhängig voneinander entwickelt

werden

• sofern gleichzeitig: Entwicklung einer Systemfamilie

Besonderheit: gemeinsame, wiederverwendbare

Komponenten können gezielt bestimmt werden


Definition

• Im Prinzip gibt es beliebige wiederverwendbare Typen:– Anforderungen, Testfälle

– Quelltexte von Programmen

– Modul-/API-Spezifikationen

– Architekturen bzw. Architekturfragmente

– Datenbankschemata

– Gestaltungselemente von GUIs

– Dokumentation: Bedien-, Installationshandbücher, Glossare

• Gegebenfalls auch (zusammenhängende) Gruppen dieser Typen, z.B. GUI besteht aus Code, Manual,…

• Schwerpunkt in der Praxis: Quelltexte, Architekturen, Modelle


Typen

• Ungeplant (Reaktiv/Extraktiv):– Komponente wird nach ihrer Entwicklung für

Wiederverwendung entdeckt

– Muss i.d.R. abgeändert / verbessert / nachdokumentiert werden

• Geplant (Proaktiv) :– Komponente von vornherein zwecks

Wiederverwendung entwickelt und gestalteta) Bibliotheksfunktionen

b) Teile eines konkreten Systems, die vermutlich später noch einmal verwendet werden können


Arten der Wiederverwendung


SOFTWARE-PRODUKTLINIEN


A software product line is an explicit specification

of commonality and variability between

[product] variants in a family of similar [software]

products by means of features.

(Pohl et al., 2005)

Produktlinien als Methode


# Produkte

Aufwand/Kosten

Konventionelle

Entwicklung

Produktlinien-

entwicklung

1 2 3 4 …

Development Effort


SPLE

● Ziel: Entwicklung einer Produktfamilie als Produktlinie

statt als einzelne Produkte

● Produktlinie deckt Anforderungen (Features) der ganzen

Domäne ab

● Abweichung vom klassischen Entwicklungsprozess und

Lebenszyklus, Unterscheidung in

– Domain Engineering

– Application Engineering



ÜbersichtD

om

ain

En

g.

Ap

pli

ca

tio

n E

ng

.

Feature-Auswahl

Feature-Modell Wiederverwendbare

Implementierungs-

artefakte

Generator Fertiges Program

[...] is the activity of collecting, organizing, and

storing past experience in building systems [...] in a

particular domain in the form of reusable assets

[...], as well as providing an adequate means for

reusing these assets (i.e., retrieval, qualification,

dissemination, adaptation, assembly, and so on)

when building new systems.

(K. Czarnecki and U. Eisenecker)

Domain Engineering


[…] has the goal of developing a specific product for the needs of a particular customer.It corresponds to the process of single application development in traditional software engineering, but reuses artifacts from domain engineering where possible.

[…] is repeated for every product of the product line that is to be derived.


(Apel et al.)

Application Engineering

Idee: Feature als ganzheitliches Abstraktionskonzept

• Feature als Domänen-Abstraktion im Problemraum der

Anwendungsdomäne

=> Spezifikation von Produktkonfigurationen

(Feature-Auswahl als Eingabe für die Produktkonfiguration)

• Feature als Implementierungskonzept im

Lösungsraum der Produktlinie

=> Spezifikation von Produktvarianten

(Feature-Auswahl als Eingabe für die Programmgenerierung)

Feature-Oriented SPLE (FOSD)



FEATURE-MODELLE



EinordnungD

om

ain

En

g.

Ap

pli

ca

tio

n E

ng

.

Feature-Auswahl


Implementierungs-

artefakte


Feature-Modelle spezifizieren den

Konfigurationsraum einer Produktlinie:

Menge der konfigurierbaren

Produktparameter:

relevante Domain Features im Problemraum

der Produktlinie

Einschränkung der Kombinierbarkeit von

Features in validen Produktkonfigurationen

durch Abhängigkeiten zwischen Features


Übersicht (1)

Darstellungsformen

Explizite Auflistung aller validen Konfigurationen: Konfigurationstabellen

Graphisch: Entscheidungsbäume, FODA Feature-Diagramme, Orthogonal Variability Model (OVM), …

Mathematisch: Aussagenlogische Terme (SAT), Constraint Satisfiability Problems (CSP), Binary Decision Diagrams (BDD), …


Übersicht (2)

FODA Feasibility Study[Kang et al., 1990]



Feature-Diagramm

Feature

Gruppe

(Cross-Tree)Constraint

Die Feature-Hierarchie bildet einen Wurzelbaum auf der Menge der Features

Das Wurzel-Feature ist per Konvention obligatorisch (engl.mandatory) und bezeichnet den Namen der Produktlinie (Konzept-Feature)

Jedes einzelne Kind-Feature ist entweder obligatorisch oder optional

=> Abhängigkeiten zwischen Nachbar-Features durch Feature-Gruppen

Feature-Hierarchie


Unter einem Eltern-Feature können mehrere Gruppen und Einzel-Features hängen

Zwei Arten von Gruppen: Alternativ (XOR) und Oder (OR)

Einzel-Features und Feature-Gruppen dürfen sich nicht überlappen

Häufig auch: Mandatory-Gruppen und Optional-Gruppen

Abhängigkeiten zwischen hierarchisch unkorreliertenFeatures durch Cross-Tree-Constraints

Feature-Gruppen


Cross-Tree Constraints

Cross-Tree Kanten können beliebig „quer“ zur Feature-Hierarchie verlaufen

Verallgemeinerung auf beliebige Cross-Tree Constraints in Form von aussagenlogischen Termen über Features


Erstellung von Feature-Diagrammen in FODA-ähnlicher Notation

Semantische Analysen: Anzahl Produktkonfiguration, Anomalien, …

Mapping in den Lösungsraum (CPP, FOP, AOP, …)


Feature-Modell Editor: FeatureIDE[Leich et al., 2005]


PRÄPROZESSOREN



EinordnungD

om

ain

En

g.

Ap

pli

ca

tio

n E

ng

.

Feature-Auswahl


Implementierungs-

artefakte


• Präprozessoren transformieren den Quelltext vor dem eigentlichen Compileraufruf

• Funktionsumfang: von einfachen #include Befehlen und bedingter Übersetzung bis zu komplexen Makrosprachen und Regeln

• Grundlage für generische Programmierung / konfigurierbare Programme / Meta-Programmierung / …

• Fester Bestandteil vieler Programmiersprachen

• C, C++, Fortran, Erlang mit eigenem Präprozessor

• C#, Visual Basic, D, PL/SQL, Adobe Flex

• Java: externe Tools

Präprozessoren


static int __rep_queue_filedone(dbenv, rep, rfp)

DB_ENV *dbenv;

REP *rep;

__rep_fileinfo_args *rfp; {

#ifndef HAVE_QUEUE

COMPQUIET(rep, NULL);

COMPQUIET(rfp, NULL);

return (__db_no_queue_am(dbenv));

#else

db_pgno_t first, last;

u_int32_t flags;

int empty, ret, t_ret;

#ifdef DIAGNOSTIC

DB_MSGBUF mb;

#endif

// over 100 lines of additional code

}

#endif

Beispiel: #ifdef in Berkley DB


class Edge {Node a, b;Color color = new Color();Weight weight;Edge(Node _a, Node _b) { a = _a; b = _b; }void print() {

if (Conf. COLORED) Color.setDisplayColor(color);a.print(); b.print(); if (Conf.WEIGHTED) weight.print();

}}

class Graph {Vector nv = new Vector(); Vector ev = new Vector();Edge add(Node n, Node m) {

Edge e = new Edge(n, m);nv.add(n); nv.add(m); ev.add(e); if (Conf.WEIGHTED) e.weight = new Weight();return e;

}Edge add(Node n, Node m, Weight w)

if (!Conf.WEIGHTED) throw RuntimeException();Edge e = new Edge(n, m);nv.add(n); nv.add(m); ev.add(e);e.weight = w; return e;

}void print() {

for(int i = 0; i < ev.size(); i++) {((Edge)ev.get(i)).print();

}}

}

class Node {int id = 0;Color color = new Color();void print() { if (Conf.COLORED) Color.setDisplayColor(color);System.out.print(id);

}}

class Color {static void setDisplayColor(Color c) { ... }

} class Weight { void print() { ... } }

class Conf {public static boolean COLORED = true;public static boolean WEIGHTED = false;

}

Beispiel: Graph SPL in Java


C-Präprozessor

Präprozessor-Direktiven sind spezielle Instruktionen im Programm-

Code, die nicht Teil des endgültigen (durch den Compiler übersetzten)

Programms sind, sondern vom Präprozessor vor der Kompilierung

verarbeitet (und dabei möglicherweise entfernt) werden.

• Der C-Präprozessor (CPP) wird vor der eigentlichen Kompilierung

aufgerufen und transformiert das Programm gemäß der im

Programm enthaltenen Direktiven

• CPP ist Teil des ANSI C Standards

• Für Präprozessor-Direktiven in C gilt

bestehen aus Zeilen beginnend mit # gefolgt vom Namen und (optionalen) weiteren Argumenten für die Direktive

dürfen sich nicht über eine Zeile hinaus erstrecken


Bestandteile von CPP

Der CPP umfasst vier Mechanismen

• Auslagern von Code und Einbinden durch Header-Files

• Makros zum Definieren/Verwenden und Finden/Ersetzen

(Expandieren) von Namen für beliebige Code-Fragmente

• Bedingte Kompilierung: optionale/alternative Code-

Fragmente vor der Kompilierung einblenden/ausblenden bzw.

auswählen.

• Explizite Deklaration und Kennzeichnung von Programmzeilen,

z.B. für Tracing, Debugging etc.

Gen

erische P

rogram

mieru

ng


Definition von Makros

#define SIZE 1020

...

foo = (char *) xmalloc (SIZE);

...

#define NEWSIZE SIZE

• Definition von Namen für beliebige Code-Fragmente

• Jedes Auftreten des Namens im nachfolgenden Programmtext wird

durch das Fragment ersetzt (expandiert)

• Fragmente können selbst wieder Makro-Namen enthalten

• Fragmente werden nicht interpretiert, sondern als einfache Strings

„kopiert“

Direktive Makro-Name Fragment Expansionsstelle Expansionsstelle


Makros mit Argumenten

#define min(X,Y) ((X) < (Y) ? (X) : (Y))

...

min(1,2) ((1) < (2) ? (1) : (2))

...

min(x+42,*p) ((x+42) < (*p) ? (x+42) : (*p))

...

min(min(a,b),c) ... // => Übung

• Argumente können an jeder Expansionsstelle neu gesetzt werden

• Genau wie Fragmente sind Argumente uninterpretierte Strings

• Schachtelung von Makro-Expansionen und/oder Argumenten

beliebig möglich

Deklaration von ArgumentnamenVorkommen von Argumentnamen

im Fragment


Bedingte Kompilierung

Markieren von Quelltextabschnitten, die beim Kompilieren unter bestimmten Bedingungen ignoriert werden, d.h. nicht in das Zielprogramm übersetzt werden

Bedingungen müssen zur Kompilierzeit auswertbar sein

Mögliche Bedingungen:

Prüfen, ob ein Name als Makro definiert/undefiniert ist

(eingeschränkte) Boole‘sche Ausdrücke über Makro-Namen und Konstanten


#if Direktive

#if expression

// conditional code

#endif

• Der conditional code kann weitere Makros enthalten

• In der expression dürfen vorkommen:

• Literale vom Typ Integer und Character

• Makro-Namen

• Arithmetische, relationale und logische Operatoren

• Namen, die keine Makros sind, werden als Konstante 0 interpretiert

#if SIZE < 1020foo = (char *)

xmalloc(SIZE);#endif


#else Direktive

#if expression

// conditional code

#else

// alternative conditional code

#endif

• Auswahl zwischen zwei alternativen Quelltext-Abschnitten

• Es wird immer genau einer der beiden conditional code Abschnitte kompiliert

#if SIZE < 1020foo = (char *)

xmalloc(SIZE);#else

foo = (char *) xmalloc(1020)#endif


#elif Direktive

#if expression

// 1. alternative conditional code

#elif expression

// 2. alternative conditional code

…

#elif expression

// n. alternative conditional code

#else

// default conditional code

#endif

• Auswahl zwischen n alternativen Quelltextabschnitten

• Die expressions müssen sich nicht zwangsläufig gegenseitig ausschließen (ähnlich zu switch-case)

Auswertungsreihenfolge


#ifdef und #ifndef

#ifdef makro-name

// conditional code

#endif

#ifndef makro-name

// conditional code

#endif

Der conditional code wird kompiliert, wenn ein Makro-Name definiert / nicht definiert (bzw. undefiniert) ist

#ifdef SIZEfoo = (char *)

xmalloc(SIZE);#endif

#ifndef SIZEfoo = (char *)

xmalloc(1020);#endif


SPL Implementierung mit CPP

TWICE

PLUS TIMES MAXBOUND

1. Feature Modell erstellenFunktion zum Verdoppeln einer Ganzzahl x

Verdoppeln von x durch Addition mit x

MAXVAL : int

Verdoppeln von x durch Multiplikation mit 2

Falls der verdoppelte Wert von x größer als der Wert MAXVAL ist, dann MAXVAL zurückgeben



2. Feature-Modell als Makrokodieren

TWICE

PLUS TIMES MAXBOUND

MAXVAL : int

#if ( defined (TWICE) && ((defined (PLUS) && ! defined (TIMES)) || (defined (TIMES) && ! defined (PLUS) )) &&(defined (MAXVAL) || ! defined (MAXBOUND) )

#define VALIDCONFIG#endif

Mandatory Root Feature

Alternativ-GruppeFeature-

Makros

Makro gesetzt, falls Konfiguration valide

Attributwert für MAXVAL gesetzt, wenn MAXBOUND gewählt



3. Parametrisierter C-Code TWICE

PLUS TIMES MAXBOUND

MAXVAL : int

#ifdef VALIDCONFIGint twice(int x) {

int y = #ifdef PLUS x+x;#elif

TIMES 2*x;#endif

#ifdef MAXBOUNDif (y > MAXVAL) return MAXVAL; else#endifreturn y;

}#endif

Nur für valide Konfigurationen wird ein Programmvariante erzeugt



4. Konfigurationen kodieren TWICE

PLUS TIMES MAXBOUND

MAXVAL : int

#define TWICE 1#define PLUS 1

#define TWICE 1#define TIMES 1

#define TWICE 1#define TIMES 1#define MAXBOUND 1#define MAXVAL 1020

#define TWICE 1#define PLUS 1#define MAXBOUND 1#define MAXVAL 1020

P1 = { TWICE, PLUS }

P2 = { TWICE, TIMES }

P3 = { TWICE, PLUS, MAXBOUND, MAXVAL=1020 }

P4 = { TWICE, TIMES, MAXBOUND, MAXVAL=1020 }

Beliebiger Wert


SPL Implementierung mit CPPint twice(int x) {

int y = x+x;return y;

}

int twice(int x) {int y = 2*x;return y;

}

int twice(int x) {int y = 2*x;if (y > 1020) return

1020; else return y;

}

int twice(int x) {int y = x+x;if (y > 1020) return

1020; else return y;

}

5. Programmvarianten

#ifdef VALIDCONFIGint twice(int x) {

int y = #ifdef PLUS x+x;#elif TIMES 2*x;#endif

#ifdef MAXBOUNDif (y > MAXVAL) return MAXVAL; else#endifreturn y;

}#endif

twice_spl.c

#define TWICE 1#define PLUS 1

#define TWICE 1#define TIMES 1

#define TWICE 1#define PLUS

1#define MAXBOUND 1#define MAXVAL 1020

#define TWICE 1#define TIMES 1#define MAXBOUND 1#define MAXVAL 1020

config1.h

config2.h

config3.h

config4.h

+

+

+

+


● Nicht nativ vorhanden

● Bedingte Kompilierung im Java-Compiler nur auf Statement-Ebene,

nicht für Klassen, Methoden und Felder

● Externe Tools vorhanden, z.B. CPP, Munge, Antenna , XVCL,

Gears, pure::variants

class Example {

public static final boolean DEBUG = false;

void main() {

System.out.println(“immer”);

if (DEBUG)

System.out.println(“debug info”);

}

}

Präprozessoren für Java

„Dead“ Code wird durch Java-Compiler entfernt


● Einfacher Präprozessor für Java Code

● Ursprünglich für Swing in Java 1.2 eingeführt

class Example {

void main() {

System.out.println(“immer”);

/*if[DEBUG]*/

System.out.println(“debug info”);

/*end[DEBUG]*/

}

}

> java Munge –DDEBUG –DFEATURE2 Datei1.java Datei2.java ... Zielverzeichnis

Konfiguration: Feature-Auswahl aus Feature-Modell

http://weblogs.java.net/blog/tball/archive/2006/09/munge_swings_se.html

MUNGE


class Edge {Node a, b;Color color = new Color();Weight weight = new Weight();Edge(Node _a, Node _b) { a = _a; b = _b; }void print() {Color.setDisplayColor(color);a.print(); b.print(); weight.print();

}}

class Edge {Node a, b;Color color = new Color();Weight weight = new Weight();Edge(Node _a, Node _b) { a = _a; b = _b; }void print() {Color.setDisplayColor(color);a.print(); b.print(); weight.print();

}}

class Edge {Node a, b;Color color = new Color();Weight weight;Edge(Node _a, Node _b) { a = _a; b = _b; }void print() {Color.setDisplayColor(color);a.print(); b.print(); weight.print();

}}

class Graph {Vector nv = new Vector(); Vector ev = new Vector();Edge add(Node n, Node m) {Edge e = new Edge(n, m);nv.add(n); nv.add(m); ev.add(e); e.weight = new Weight();return e;

}Edge add(Node n, Node m, Weight w)Edge e = new Edge(n, m);nv.add(n); nv.add(m); ev.add(e);e.weight = w; return e;

}void print() {for(int i = 0; i < ev.size(); i++) {((Edge)ev.get(i)).print();

}}

}

class Graph {Vector nv = new Vector(); Vector ev = new Vector();Edge add(Node n, Node m) {Edge e = new Edge(n, m);nv.add(n); nv.add(m); ev.add(e); e.weight = new Weight();return e;

}Edge add(Node n, Node m, Weight w)Edge e = new Edge(n, m);nv.add(n); nv.add(m); ev.add(e);e.weight = w; return e;

}void print() {for(int i = 0; i < ev.size(); i++) {((Edge)ev.get(i)).print();

}}

}

class Node {int id = 0;Color color = new Color();void print() { Color.setDisplayColor(color);System.out.print(id);

}}

class Node {int id = 0;Color color = new Color();void print() { Color.setDisplayColor(color);System.out.print(id);

}}

class Color {static void setDisplayColor(Color c) { ... }

}

class Weight { void print() { ... } }

Beispiel: Graph SPL


/*if[WEIGHT]*/class Weight { void print() { ... } }/*end[WEIGHT]*/

class Edge {Node a, b;/*if[COLOR]*/Color color = new Color();/*end[COLOR]*//*if[WEIGHT]*/Weight weight;/*end[WEIGHT]*/Edge(Node _a, Node _b) { a = _a; b = _b; }void print() {/*if[COLOR]*/Color.setDisplayColor(color);/*end[COLOR]*/a.print(); b.print(); /*if[WEIGHT]*/weight.print();/*end[WEIGHT]*/

}}

class Graph {Vector nv = new Vector(); Vector ev = new Vector();Edge add(Node n, Node m) {Edge e = new Edge(n, m);nv.add(n); nv.add(m); ev.add(e); /*if[WEIGHT]*/e.weight = new Weight();/*end[WEIGHT]*/return e;

}/*if[WEIGHT]*/Edge add(Node n, Node m, Weight w)Edge e = new Edge(n, m);nv.add(n); nv.add(m); ev.add(e);e.weight = w; return e;

}/*end[WEIGHT]*/void print() {for(int i = 0; i < ev.size(); i++) {((Edge)ev.get(i)).print();

}}

}

class Node {int id = 0;/*if[COLOR]*/

Color color = new Color();/*end[COLOR]*/

void print() { /*if[COLOR]*/Color.setDisplayColor(color);/*end[COLOR]*/System.out.print(id);

}}

/*if[COLOR]*/class Color {static void setDisplayColor(Color c) { ... }

}/*end[COLOR]*/

Graph SPL mit MUNGE


● Präprozessor-Direktive #ifdef wie in cpp

● Sammlung von Ant-Tasks für Java ME

● In vielen Java ME Projekten eingesetzt

Antenna

Bedingte Kompilierung objektorienter Programm-Elemente in Java Klassen und Interfaces Methoden und Member-

Variablen Klassenvariablen und

statische Methoden Statements …


Antenna - Beispiel

//#ifdef midp20//# import javax.microedition.lcdui.game.Sprite;//#endif//#ifdef siemens//# import com.siemens.mp.game.Sprite//#endif

<wtkpreprocesssrcdir="src“ destdir="siemens“ symbols="siemens“ verbose="true"/>

(build.xml)

//#ifdef midp20//# import javax.microedition.lcdui.game.Sprite;//#endif//#ifdef siemensimport com.siemens.mp.game.Sprite//#endif


● In vielen Sprachen bereits enthalten / einfach verwendbare

Tools

● Den meisten Entwicklern bereits bekannt

● Sehr einfaches Programmierkonzept: markieren und

entfernen

● Sehr flexibel / ausdrucksstark, beliebige Granularität

● Nachträgliche Einführung von Variabilität in bestehendes

Projekt einfach

Vorteile von Präprozessoren


● Vermischung von zwei Sprachen

(C und #ifdef, oder Java und

Munge, …)

● Kontrollfluss schwer

nachvollziehbar

● Lange Annotationen schwer zu

finden

● Zusätzliche Zeilenumbrüche

zerstören Layout

● Vermischung von syntaktischer

Variation und Programmsemantik

class Stack {

void push(Object o

#ifdef SYNC

, Transaction txn

#endif

) {

if (o==null

#ifdef SYNC

|| txn==null

#endif

) return;

#ifdef SYNC

Lock l=txn.lock(o);

#endif

elementData[size++] = o;

#ifdef SYNC

l.unlock();

#endif

fireStackChanged();

}

}

Alternativ: Feature-Code

separieren/modularisieren?

Nachteile: Unleserlicher Code


● Hohe Komplexität durch beliebige Schachtelung

● Fehleranfälligkeit durch Komplexität und unstrukturierten

(„undisziplinierten“) Einsatz

Beispiele:

• Variabler Rückgabetyp => Typanalyse?

• „Derivate“-Kommata bei Separierung variabler Parameter

Edge/*if[WEIGHT]*/Weight/*end[WEIGHT]*/ add(Node n, Node m /*if[WEIGHT]*/, int w/*end[WEIGHT]*/) {return new Edge/*if[WEIGHT]*/Weight/*end[WEIGHT]*/ (n, m /*if[WEIGHT]*/, w/*end[WEIGHT]*/ );

}

Edge set(/*if[WEIGHT]*/int w/*if[COLOR]*/, /*end[COLOR]/*end[WEIGHT]*//*if[COLOR]*/int c/*end[COLOR]*/) {

…}

Weitere Nachteile


● Feature-Code ist komplett verstreut

– Feature-Traceability-Problem

– Beispiel Graph-SPL: Wie findet man einen Fehler in der

Implementierung des Weight Features?

● Verhindert/erschwert Tool Support

– Negative Erfahrungen bereits bekannt von der Analyse von C/C++

(Refactoring, Typ-Analyse, …)

– MUNGE und andere: Definition in Kommentaren

Weitere Nachteile


“#ifdef considered harmful”

“#ifdef hell”

Designed in the 70th and hardly evolved since

“preprocessor diagnostics are poor”

“is difficult to determine if the code being

viewed is actually compiled into the system”

“programming errors are easy

to make and difficult to detect”

“incomprehensible source texts”

“maintenance becomes a ‘hit or miss’ process”

“CPP makes maintenance difficult”

“source code rapidly

becomes a maze”

Kritik an Präprozessoren


● Entwurf neuartiger Implementierungskonzepte und

Sprachkonstrukte für Variabilität auf Programmebene

● Lösungsansätze für

– Feature Traceability

– Querschneidende Belange (Crosscutting Concerns)

– Unflexible Vererbungshierarchien

● Feature-orientiert: Modulare Feature-Implementierung

(zumindest Kohäsion)

Ziele von Programmierparadigmen

für SPL


ST2


HAUSAUFGABE


• Implementierung des PONG Projekts als

(reaktive) Produktlinie

– Domänenentwicklung

• Feature-Modell: FODA / FeatureIDE

• Präprozessor-Implementierung: Java + MUNGE

– Applikationsentwicklung

• Konfiguration(en): FeatureIDE

• Produktgeneration: FeatureIDE


Aufgabenestellung

Pong Einzelprodukt Pong SPL


Übersicht

• Abbildung von gegebenem Feature-Modell in Feature IDE

• Erweiterungen in der Implementierung(auf Basis der Features im Modell)

• Sinnvolle Abbildung von Features zuImplementierungsartefakten

• Änderungen der (Aufrufer/Klassen)Struktur, falls notwendig

• Generierung aller Varianten

• Testweise Ausführung jeder Variante


Arbeitsschritte

Apel et al.:Feature-Oriented Software Product Lines,

2013.

Hauptliteratur zu SPLE

Exemplar in der UB verfügbar

ISBN 978-3-642-37521-7


Literatur

Pohl et al.: Software Product Line Engineering, 2005.

Frei im Uni-Netz verfügbar(Springer Link)

ISBN 978-3-540-28901-2


Literatur

P. Clements, L. M. Northup:

Software Product Lines:

Practices and Patterns, 2006.

Weiterführende Literatur

ISBN: 0-201-70332-7


Literatur

Kyo C. Kang, Sholom G. Cohen, James A. Hess, William E. Novak, and A. Spencer Peterson.Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical report, Carnegie-Mellon University Software Engineering Institute, November 1990.

Thomas Leich, Sven Apel, Laura Marnitz, and Gunter Saake. Tool Support for Feature-orientedSoftware Development: FeatureIDE: an Eclipse-based Approach. In Proceedings of the OOPSLA workshop on Eclipse technology eXchange, eclipse ’05, pages 55–59, New York, NY, USA, 2005. ACM.

David Benavides, Sergio Segura, and Antonio Ruiz-Cortés. Automated Analysis of Feature Models 20 Years Later: A Literature Review. Advanced Information Systems Engineering, 35:615–636, September 2010.

Pierre-Yves Schobbens, Patrick Heymans, and Jean-Christophe Trigaux. Feature Diagrams: A Survey and a Formal Semantics. In Requirements Engineering, 14th IEEE International Conference, pages 139 –148, sept. 2006.

Don Batory. Feature Models, Grammars, and Propositional Formulas. In SPLC, pages 7–20. Springer, 2005.

Arnaud Hubaux: Feature-based Configuration: Collaborative, Dependable, and Controlled.PhD thesis, University of Namur, Belgium, 2012.

Richard M. Stallman: The C Preprocessor. Last Revised July 1992 for GCC v.2. https://gcc.gnu.org/onlinedocs/cpp/

Tom Ball: Munge: Swing's Secret Preprocessor. https://weblogs.java.net/blog/tball/archive/2006/09/munge_swings_se.html

Jörg Pleumann, Omry Yadan, Erik Wetterberg: Antenna – An Ant-To-End Solution for Wireless Java. Version 1.2.1. http://antenna.sourceforge.net/


Referenzen

Documents

Lehrstuhl Praktische Informatik Wiederverwendung von Softwarepi.informatik.uni-siegen.de/lehre/Vertiefungspraktika/2017s/materials/slides/2017s_PEP... · • Im Prinzip gibt es beliebige