softwareproduktlinien - dbse.ovgu.de · stand 2005 (i) 5 vorgängersysteme, nicht interoperabel...

Softwareproduktlinien - Entwicklungsprozess und Variabilitätsmodellierung

Sven Apel (Universität Passau) Christian Kästner (Universität Marburg) Gunter Saake (Universität Magdeburg)

Thomas Thüm (TU Braunschweig)

1

Agenda

Produktlinien Was ist ein Feature? Domain Engineering vs. Application Engineering Feature-Modellierung

2

Produktlinien

A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

Software Engineering InstituteCarnegie Mellon University

3

Produktlinien

Eine Menge von Programmvarianten (Software-Produkten),

…teilen eine gemeinsame Menge von Merkmalen (Features)

...die auf ein gemeinsames Marktsegment (Domäne) zugeschnitten sind

...mit dem Ziel der Wiederverwendung von gemeinsamen Software-Artefakten

z. B. Datenbank-Produktlinie für eingebettete Systeme

4

Domäne

Die Produkte einer Produktlinie sind zugeschnitten auf ein Anwendungsgebiet

Dieses Anwendungsgebiet wird als Domäne bezeichnet Horizontale Domänen

Abrechnungen, Lagerverwaltung, Flugbuchung Vertikale Domänen

Numerische Algorithmen, Netzwerktreiber, GUIs, Datenbanken

5

Was ist ein Feature? (deutsch Merkmal)

Domänenabstraktion Features repräsentieren Anforderungen, Gemeinsamkeiten

bzw. Unterschiede von Produktvarianten Mittel zur Kommunikation zwischen Stakeholdern Dient zur Spezifikation von Produktvarianten

Feature-Auswahl als Eingabe für die Produktgenerierung Aber: es gibt auch Belange, die keine Features sind

6

Belang vs. Feature

Belang (siehe spätere Kapitel) Jedwede Problemstellung, die von Interesse ist

Feature Problemstellung, die eine besondere Bedeutung in einer

Domäne hat Konfigurationsoption

Belange Features

7

Features vs. Varianten

Features sind Grundbausteine einer Produktlinie (z.B. implementiert durch Komponenten, Packages, etc.)

Feature-Kombinationen bilden individuelle Produkte

8

Features in Datenbanken

Transaktionsverwaltung Log & Recovery Schreibzugriff Persistenz / In-Memory Seitenverdrängungsstrategien LRU / LFU / Clock /... Sortierverfahren Datentypen variabler Länge Gruppieren, Aggregation Windows / Unix / NutOS / TinyOS / …

9

Entwicklung einer Produktlinie

Entwicklung einer Produktlinie statt einzelner Produkte Produktlinie deckt Anforderungen der ganzen Domäne ab Abweichung vom klassischen Entwicklungsprozess und

Lebenszyklus Unterscheidung in

Domain Engineering Application Engineering

10

Software Lebenszyklus – Klassisch

11

Domain Engineering

[...] 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. Eisenecker12

Application and Domain Engineering

13

Entwicklungsaufwand

# Produkte

Aufwand/KostenKonventionelle Entwicklung

Produktlinien-entwicklung

1 2 3 4 …

14

Scoping

Eingrenzung der Domäne Welche Features sind relevant/sollen entwickelt werden Oft wirtschaftliche Entscheidung

15

[Schmid 2002]

Exkurs: Ansätze zur Einführung von Produktlinien Es gibt drei übliche Ansätze eine Softwareproduktlinie zu

erstellen / den Ansatz einzuführen Proaktives Vorgehensmodell Reaktives Vorgehensmodell Extraktives Vorgehensmodell

Für alle Implementierungstechniken Auswahl anhand betrieblicher Gesichtspunkte

(Kosten, Risiko, Chancen, ...)

16

Exkurs: Proaktives Vorgehensmodell

Produktlinie neu entwerfen und implementieren; wie bisher besprochen

Komplette Domänenanalyse zu Beginn Kann die normale Entwicklung für mehrere Monate

unterbrechen, bis die Produktlinie auf dem Stand der bestehenden Produkte ist

Hohe Kosten und hohes Risiko Gut wenn Anforderungen wohl-definiert sind

17

18

[Krueger 2002]

Exkurs: Reaktives Vorgehensmodell

Analog zu Spiralmodell oder Extreme Programming Implementiert zuerst wenige Produktvarianten; fügt

inkrementell weitere hinzu Geeignet, wenn benötigte Varianten nicht komplett im

voraus bekannt, und für unvorhergesehene Änderungen Kleinere Projektgröße, geringere Anfangskosten; weniger

Ressourcenbindung, schnellere Ergebnisse Später evtl. Umstrukturierungen nötig

19

20

[Krueger 2002]

Exkurs: Extraktives Vorgehensmodell

Nutzt eine oder mehrere bestehende Produkte als Basis Extrahiert daraus Features und erlaubt so

Produktvarianten zu erzeugen Geeignet für den schnellen Wechsel von traditionellen

Anwendungen zu Produktlinien Relativ geringer Ressourcenaufwand und Risiko Sehr anspruchsvoll für Werkzeuge und Sprachen, da

Zerlegung einer Anwendung, die nicht als Produktlinie entworfen wurde

21

22

[Krueger 2002]

Feature-Modellierung

Beschreibung der Features einer Domäne Zur Visualisierung und Kommunikation Ein Feature-Modell beschreibt…

die elementaren Abstraktionen einer Domäne und deren Beziehungen

die Menge der Produkte einer Produktlinie Ein Feature-Diagramm visualisiert Features und deren

Beziehungen

23

Gültige Feature-Auswahl?

Transaktionsverwaltung Log & Recovery Schreibzugriff Persistenz / In-Memory Seitenverdrängungsstrategien LRU / LFU / Clock /... Sortierverfahren Datentypen variabler Länge Gruppieren, Aggregation Windows / Unix / NutOS / TinyOS / …

24

Feature-Modell: Beispiel

Features: Basis, Txn, Write, Win, Unix Abhängigkeiten:

Basis muss immer ausgewählt sein und braucht Win oder Unix Win darf nie zusammen mit Unix ausgewählt werden Wenn Txn ausgewählt ist muss auch Write ausgewählt sein

Wieviele Varianten möglich? Sechs mögliche Varianten {Basis, Win}, {Basis, Unix}, {Basis, Win, Write}, {Basis, Unix,

Write}, {Basis, Win, Write, Txn}, {Basis, Unix, Write, Txn}

26

Feature-Modell als aussagenlogischer Ausdruck Variable für jedes Feature (wahr wenn ausgewählt) Formel beschreibt Feature-Modell Formel wahr für gültige Feature-Auswahl

Erlaubt automatische Überprüfung, und Aufzählen der gültigen Produktvarianten (SAT, BDD, …)

27

)(

)()(

WriteTxn

WinUnixWinUnixBasis

Feature-Diagramm

Graphische Darstellung, hierarchische Struktur Kinder: optional, obligatorisch, oder, alternativ Abstrakt vs konkret: ohne vs mit Bezug zur

Implementierung Abstrakte Features haben keinen Einfluss auf Produkte

obligatorischoptional

oder (min 1)alternativ (genau 1)

28

abstrakt

konkret

Tool Demo: FeatureIDE

29

Beispiel: Sternenflotten-Produktlinie

Hair Gender Body

Officer

Feature-Diagramm vs. Formeln

Besser lesbar als Formel (“Management-kompatibel”)

Weniger flexibel extra Formeln möglich Übersetzung „Diagramm Formel” automatisierbar

31



Weniger flexibel extra Formeln möglich Übersetzung „Diagramm Formel” automatisierbar

32



Weniger flexibel extra Formeln möglich / notwendig Übersetzung „Diagramm Formel” automatisierbar

33

Beispiel – FAME DBMS (Core)

34

Beispiel – Berkeley DB (refaktorisiert)

35

PicoDBMS

(Für Smartcards)

Comet DB

(Für Sensornetzwerke)

Feature-Modell eines Speichermanagers

GUIDSL-Format

Speichern des Feature-Diagramms als Grammatik Satz der Grammatik ist gültige Konfiguration Innere Features sind abstrakt, Blätter sind konkret

HowTo: http://www.cs.utexas.edu/users/dsb/fopdocs/guidsl.html39

Pr : Select+ :: _Pr ;Select : Feature1 | Feature2 ;

Pr: Feature1 Nesting Feature4::_Pr;Nesting: Feature2 Feature3::_Nesting;

Pr: [Feature1] [Feature2] Feature3 ::_Pr;

Feature-Diagramm – Varianten

Viele verschiedene Varianten in der Literatur, z. B. Innere Features konkret oder abstrakt Mandatory/Optional in Oder/Alternative-Gruppen Requires/Excludes Pfeile

Konvertierungen i.d.R. möglich

requires

40

Konfiguration einer Variante

GUIDSLFeatureIDE

41

FeatureIDE

42

Entwurf und Implementierung von Features

Nach der Feature-Modellierung folgt der Entwurf und die Implementierung...

Dom

ain

Eng.

Appl

icat

ion

Eng.

Feature-Auswahl

Feature-Modell WiederverwendbareImplementierungs-artefakte

Generator Fertiges Program

43

Zusammenfassung

Produktlinien als Konzept zur systematischen Wiederverwendung

Entwicklung teilt sich in Domain Engineering und Application Engineering

Features repräsentieren Domänenkonzepte Produkte einer Produktlinie haben gemeinsame Features Feature-Modelle beschreiben Features und ihre

Abhängigkeiten… …und werden zur Konfiguration benutzt

44

Ausblick

Nächste Kapitel handeln von Methoden, Techniken und Werkzeugen zur Implementierung von Produktlinien

45

Literatur I

S. Apel, D. Batory, C. Kästner, and G. Saake. Feature-Oriented Software Product Lines - Concepts and Implementation. Springer, 2013. Part 1: Software Product Lines

K. Kang, S. Cohen, J. Hess, W. Novak, and A. Peterson. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21, SEI,1990.[Frühe Ideen zur Domänenanalyse mit Feature-Modellen]

K. Czarnecki and U. Eisenecker. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000.[Umfassende Beschreibung von Domain Engineering, Feature-Diagrammen und deren Normalisierung]

46

Literatur II

D. Batory. Feature Models, Grammars, and Propositional Formulas, In Proc. of Software Product Line Conference (SPLC), 2005

Allgemeine Bücher zu Produktlinien: P. Clements, L. Northrop, Software Product Lines : Practices

and Patterns, Addison-Wesley, 2002 K. Pohl, G. Böckle, F. van der Linden, Software Product Line

Engineering: Foundations, Principles, and Techniques, Springer, 2005

47

Praktisches Beispiel: Microsoft

Entwicklungsabteilung Visual Studio .Net Framework

Erfahrungsbericht der Entwicklung als Produktlinie, VS2005 vs. VS2008 (Kapitel 9) 3 500 Entwickler 20 000 000 Quelldateien 700 000 Arbeitselemente 2 000 Nightly Builds 15 Terabyte Daten Viel Variabilität

(Editionen, Komponenten, …)

48

Stand 2005 (i)

5 Vorgängersysteme, nicht interoperabel Codemanagement, Bug-Tracking, Build-Automatisierung,

Testfall- und Testsystem Management Alles Eigenentwicklungen, die über Jahrzehnte isoliert waren

Heterogener, geschäftlicher Kontext Freie Software (Silverlight, Express-Versionen, .Net) mit Ziel

Kunden zu binden und dabei zu helfen für Microsoft-Systeme zu entwickeln

Kommerzielle Systeme (z.B. Visual Studio, MSDN) mit Abo-Modell

Spannungsverhältnis zwischen Geschäftszielen, die oft entgegengesetzt waren

49

Stand 2005 (ii)

Kein zentral Verantworlicher Keine “Produkt-Backlogs” vorhanden, welche die

Anforderungen grob zusammenfassen, um Abgleiche zu ermöglichen “Im wahrsten Sinne des Wortes hatte niemand die Möglichkeit, eine

Liste von mehr als 1 000 Features zusammenzufassen.” 5 Verhaltensweisen der Abteilungen

Nicht-Angriffspakt zwischen Managern Schedule Chicken: Keine Abteilung konnte Zeitplan einhalten, wusste

aber, dass auch die anderen es nicht können Kennzahlen sind für andere (aber nicht für mich) Unsere Kunden sind anders (aufgrund der Breite der Domäne) Unsere Gruppe ist besser

50

Verschwendung von Resourcen

Entwicklung offener Bugs der Beta-1 von VS2005

51

Auf die nächste Version verschobene Bugs.(Müssen 2x angefasst werden)

©Visual Studio Team Foundation Server 2012Adopting Agile Software Practices

Verbesserungen nach 2005 (i)

Aufräumen und Ordnung halten Vor Beginn der Implementierung alle offenen Bugs beheben

Strengeres Timeboxing Statt 3 Monatsplan 3 wöchige „Sprints“ zur Fertigstellung

von Features Ziel: Nach jedem Sprint potentiell auslieferbare Produkte mit

Inkrement in Funktionalität oder Qualität Feature-Crews

Kleine, interdisziplinäre Teams (5—6 Entwickler und Tester + Manager)

Arbeiten an isolierten Zweig der Codebasis mit speziellen Abgeschlossenheitskriterien (Modularität!)

52

Feature-Crews und Product Units (PU)

Integration (in Main Branch) und Isolation (von Änderungen anderer Crews)

53

Test auf Qualitätsmerkmale(Tests, Source Code)

Verbesserungen nach 2005 (ii)

Product-BackLogs “DevDiv was an organization conditioned over a decade to think in terms of

features. Define the features, break them down into tasks, work through the tasks, and so on. The problem with this granularity is that it encourages “peanut buttering”, an insidious form of overproduction.”

Neue Struktur: Mehrwert, Nutzererlebnis und Funktionalität wird beschrieben mit vorgeschriebenen Fragen auf diesen Ebenen, um die Granularität der Features zu definieren

54©Visual Studio Team Foundation Server 2012Adopting Agile Software Practices

Grob granular, verständlich für Kunden

Fein granular, präzise für Entwickler

Ergebnisse (i)

Features waren zum einen abstrakt genug, um für einen Kunden interessant oder von einem anderen Feature nutzbar zu sein, und zum anderen detailliert genug, um in 3 Wochen implementierbar zu sein


Ergebnisse (ii)

Entwicklungszeit halbiert bis zum neuen Release 15x weniger Bugs Größere Kundenzufriedenheit


Quiz

Wie viele Varianten beschreibt das Feature-Modell:

Sind Android und die C++-Standard-Template-Library Produktlinien? Begründe!

57

(a) (b)

)(

)()(

WriteTxn

WinUnixWinUnixBasis

softwareproduktlinien - dbse.ovgu.de · stand 2005 (i) 5 vorgängersysteme, nicht interoperabel...

Documents