Softwareproduktlinien - Entwicklungsprozess und Variabilitätsmodellierung

Transkript

1 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

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

3 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 Institute Carnegie Mellon University 3

4 Produktlinien Eine Menge von Programmvarianten (SoftwareProdukten), 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

5 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 5 Numerische Algorithmen, Netzwerktreiber, GUIs, Datenbanken

6 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

7 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 7 Features

8 Features vs. Varianten Features sind Grundbausteine einer Produktlinie (z.b. implementiert durch Komponenten, Packages, etc.) Feature-Kombinationen bilden individuelle Produkte 8

9 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

10 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 10 Domain Engineering Application Engineering

11 Software Lebenszyklus Klassisch 11

12 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. Eisenecker 12

13 Application and Domain Engineering 13

14 Entwicklungsaufwand Aufwand/Kosten Konventionelle Entwicklung Produktlinienentwicklung # Produkte

15 Scoping Eingrenzung der Domäne Welche Features sind relevant/sollen entwickelt werden Oft wirtschaftliche Entscheidung [Schmid 2002] 15

16 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

17 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] 18

19 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] 20

21 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] 22

23 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

24 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

25 25

26 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? 26 Sechs mögliche Varianten {Basis, Win}, {Basis, Unix}, {Basis, Win, Write}, {Basis, Unix, Write}, {Basis, Win, Write, Txn}, {Basis, Unix, Write, Txn}

27 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 Basis (Unix Win ) (Unix Win ) (Txn Write ) Erlaubt automatische Überprüfung, und Aufzählen der gültigen Produktvarianten (SAT, BDD, ) 27

28 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 abstrakt optional alternativ (genau 1) konkret 28 obligatorisch oder (min 1)

29 Tool Demo: FeatureIDE 29

30 Beispiel: Sternenflotten-Produktlinie Officer Hair Gender Body

31 Feature-Diagramm vs. Formeln Besser lesbar als Formel ( Management-kompatibel ) Weniger flexibel extra Formeln möglich Übersetzung Diagramm Formel automatisierbar 31

32 Feature-Diagramm vs. Formeln Besser lesbar als Formel ( Management-kompatibel ) Weniger flexibel extra Formeln möglich Übersetzung Diagramm Formel automatisierbar 32

33 Feature-Diagramm vs. Formeln Besser lesbar als Formel ( Management-kompatibel ) Weniger flexibel extra Formeln möglich / notwendig Übersetzung Diagramm Formel automatisierbar 33

34 Beispiel FAME DBMS (Core) 34

35 Beispiel Berkeley DB (refaktorisiert) 35

36 PicoDBMS (Für Smartcards)

37 Comet DB (Für Sensornetzwerke)

38 Feature-Modell eines Speichermanagers

39 GUIDSL-Format Speichern des Feature-Diagramms als Grammatik Satz der Grammatik ist gültige Konfiguration Innere Features sind abstrakt, Blätter sind konkret Pr: [Feature1] [Feature2] Feature3 ::_Pr; Pr : Select+ :: _Pr ; Select : Feature1 Feature2 ; Pr: Feature1 Nesting Feature4::_Pr; Nesting: Feature2 Feature3::_Nesting; 39 HowTo:

40 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

41 Konfiguration einer Variante FeatureIDE 41 GUIDSL

42 FeatureIDE 42

43 Entwurf und Implementierung von Features Nach der Feature-Modellierung folgt der Entwurf und die Implementierung... Feature-Modell Wiederverwendbare Implementierungsartefakte Application Eng. Domain Eng. Feature-Auswahl 43 Generator Fertiges Program

44 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

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

46 Literatur I S. Apel, D. Batory, C. Kästner, and G. Saake. FeatureOriented Software Product Lines - Concepts and Implementation. Springer, 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, [Umfassende Beschreibung von Domain Engineering, Feature-Diagrammen und deren Normalisierung] 46

47 Literatur II D. Batory. Feature Models, Grammars, and Propositional Formulas, In Proc. of Software Product Line Conference (SPLC), 2005 Allgemeine Bücher zu Produktlinien: 47 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

48 Praktisches Beispiel: Microsoft Entwicklungsabteilung Visual Studio.Net Framework Erfahrungsbericht der Entwicklung als Produktlinie, VS2005 vs. VS2008 (Kapitel 9) Entwickler Quelldateien Arbeitselemente Nightly Builds 15 Terabyte Daten Viel Variabilität (Editionen, Komponenten, )

49 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 49 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 AboModell Spannungsverhältnis zwischen Geschäftszielen, die oft entgegengesetzt waren

50 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 Features zusammenzufassen. 5 Verhaltensweisen der Abteilungen 50 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

51 Verschwendung von Resourcen Entwicklung offener Bugs der Beta-1 von VS2005 Auf die nächste Version verschobene Bugs. (Müssen 2x angefasst werden) 51 Visual Studio Team Foundation Server 2012 Adopting Agile Software Practices

52 Verbesserungen nach 2005 (i) Aufräumen und Ordnung halten Strengeres Timeboxing Vor Beginn der Implementierung alle offenen Bugs beheben 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 52 Kleine, interdisziplinäre Teams 6 Entwickler und Tester + Manager) Arbeiten an isolierten Zweig der Codebasis mit speziellen Abgeschlossenheitskriterien (Modularität!) (5

53 Feature-Crews und Product Units (PU) Integration (in Main Branch) und Isolation (von Änderungen anderer Crews) Test auf Qualitätsmerkmale (Tests, Source Code) 53

54 Verbesserungen nach 2005 (ii) Grob granular, Product-BackLogs verständlich für Kunden 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. 54 Neue Struktur: Mehrwert, Nutzererlebnis und Funktionalität wird beschrieben mit vorgeschriebenen Fragen auf diesen Ebenen, um die Granularität der Features zu definieren Visual Studio Team Foundation Server 2012 Adopting Agile Software Practices Fein granular, präzise für Entwickler

55 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 55 Visual Studio Team Foundation Server 2012 Adopting Agile Software Practices

56 Ergebnisse (ii) Entwicklungszeit halbiert bis zum neuen Release 15x weniger Bugs Größere Kundenzufriedenheit 56 Visual Studio Team Foundation Server 2012 Adopting Agile Software Practices

57 Quiz Wie viele Varianten beschreibt das Feature-Modell: (a) (b) Basis (Unix Win ) (Unix Win ) (Txn Write ) Sind Android und die C++-Standard-Template-Library Produktlinien? Begründe! 57