Verfolgbarkeit von Variabilität in Software-Produktlinine

Seminar: „Neue Ansätze der Softwarequalitätssicherung“ – Prof. Dr. Engels - SS2009 

Verfolgbarkeit von Variabilität in 

Software-Produktlinien 

• Software-Produktlinien 

Christoph Oberhokamp 

09.07.2009 

Agenda 

– Grundlagen 

– Entwicklungsprozess 

– Variabilität in SPL 

• Variabilitätsmanagement in Software-Produktlinien 

• Verfolgbarkeit von Variabilität in Software-Produktlinien 

– Grundproblem 

– Vorstellung ausgewählter Lösungsansätze 

• Zusammenfassung und Ausblick 

Software-Produktlinen Variabilitätsmanagement in SPL Verfolgbarkeit von Variabilität in SPL Lösungsansätze 

2 

09.07.2009 

1

Gemeinsamkeiten und Unterschiede 

Modell 1 Modell 2 Modell 3 

• Aktuell 136 Modelle erhältlich! 

• Entwicklung der Software? 

Modell 4 

Modell 5 

Software-Produktlinie Quelle: www.nokia.de 


• Software-Produktlinien – Idee 

Software-Produtklinien 

– Mehrere Software-Produkte aus möglichst vielen gemeinsamen Teilen 

entwickeln 

– Entwicklungsaufwand für diese Teile nur einmal leisten 

Konsequente Wiederverwendung von Entwicklungsartefakten 

– Anforderungen, Spezifikationen, Architekturbeschreibungen, Quellcode, Testfälle 

– Gleichzeitig besitzt jedes Produkt spezifische Teile 

• Produkte einer SPL – Ausrichtung 

– Software-Produkte sind für ein bestimmtes Geschäftsfeld (Domäne) 

bestimmt 

• Informationssysteme (CRM-Systeme, ERP-Systeme) 

• Eingebettete Systeme (Kfz-, Schiffs- und Flugzeugelektronik, Telekommunikation) 


3 

4 

09.07.2009 

2

• SPL-Entwicklung – Vorteile 

– Reduzierung der Entwicklungskosten 

– Verbesserung der Software-Qualität 

– Verkürzung des Time-to-Market 

– Reduzierung des Wartungsaufwands 

– Verbesserung der Kostenschätzung 

• SPL-Entwicklung – Nachteile 

– Höherer Aufwand / Vorausleistung 

– Verlangt Voraussagefähigkeit 


Plattform 

Produkt 

Plattform 

Analyse 

Produkt 

Analyse 

* 

* 

* 

* 

Plattform 

Design 

1 * 1 

Produkt 

Design 

Vorteile von Software-Produtklinien 

SPL-Entwicklungsprozess 

Plattform 

Implementierung 

Produkt 



1 

1..* 

1 * 

1 

1..* 

1 

Plattform Test 

Produkt Test 

Quelle: abgewandelt aus [5] 

5 

6 

09.07.2009 

3

Variabilität in Software-Produktlinien 

• Zentrales Konzept für die Definition und Dokumentation 

der Variabilität einer SPL sind Variationspunkte und 

Varianten 

• Variationspunkt 

– Ein Variationspunkt definiert, was variieren kann 

• Variante 

– Eine Variante beschreibt eine konkrete Auswahl 

Variabilitätsmanagement 


• Verwaltung von Variabilität in einer SPL 

Plattform 

* 

* 

Plattform 

Design 

1 * 1 

Produkt 

Design 

Variabilitätsmanagement in SPL 

– Variationspunkte und deren Beziehungen zueinander 

– Über den gesamten Software-Entwicklungsprozess hinweg 

– Unabhängig von der Abstraktionsebene 

Plattform 

Analyse 

* 

* 

Plattform 

Design 

1 * 1 

Plattform 


Allgemeingültiger Variabilitätsmanagement-Ansatz 


1 

1..* 

1 


* 

* 

1 

1..* 

1 * 

1 

1..* 

1 

7 

8 

09.07.2009 

4

Variabilitätsmanagement-Ansatz 

• Anforderungen an einen allgemeingültigen 

Variabilitätsmanagement-Ansatz für SPL nach Berg und Muthig [1] 

– Konsistenz, Skalierbarkeit, Verfolgbarkeit, Visualisierung 

• Konsistenz 

– Variabilität in den verschiedenen Entwicklungsphasen und auf den 

verschiedenen Abstraktionsebenen gleich handhaben 

– Konfusion und fehlerhaften Gebrauch des Ansatzes vorbeugen 


• Skalierbarkeit 





– Die Variabilität muss leicht handhabbar sein, egal ob es sich um eine 

einzelne Komponente oder um ein komplexes System handelt 


9 

10 

09.07.2009 

5

• Verfolgbarkeit 





– Variabilität in verschiedenen Entwicklungsphasen und auf verschiedenen 

Abstraktionsebenen steht im Zusammenhang zueinander 

– Zusammenhänge müssen miteinander verknüpft und verwaltet werden 

– Vereinfachung der Wartbarkeit und der Evolution einer Software- 

Produktlinie 


• Visualisierung 





– Visualisierung der Variabilität und der Abhängigkeiten zwischen 

Produkten in einer Produktlinie 

– Verbesserter Überblick über die Zusammenhänge 

– Fördert die Verständlichkeit und Wartbarkeit 


11 

12 

09.07.2009 

6

Anforderungen 





Verfolgbarkeit von Variabilität in Software-Produktlinien 


1 

4 

Plattform 

Produkt 

Plattform 

Analyse 

Produkt 

Analyse 

3 

5 

* 

* 

* 

* 

Verfolgbarkeit von Variabilität in SPL 

Plattform 

Design 

1 * 1 

1 

1..* 

Produkt 

Design 

1 * 

1 

1..* 

1 

* * 

Plattform 


Produkt 



2 


2 2 2 

3 3 3 

Produkt Test 

5 5 5 

13 

14 

09.07.2009 

7

– Variabilität 

• Horizontal 

• Vertikal 

– Evolution 

AnforderungsAnforderungsdefinitiondefinition 

funktionaler 

funktionaler 

Systementwurf 

Systementwurf 

technischer 

technischer 

Systementwurf 

Systementwurf 

KomponentenKomponentenspezifikationspezifikation 

Arten an Verfolgbarkeit in SPL 

Programmierung 

Programmierung 

Komponententest 

Komponententest 

Abnahmetest 

Abnahmetest 

Systemtest 

Systemtest 

Integrationstest 

Integrationstest 

Quelle: entnommen aus [3] 


Verfolgbarkeit von Variabilität in SPL 

– Verfolgbarkeits-Verknüpfungen zwischen 

• Variationspunkten und ihren Varianten 

• Varianten untereinander 

• Variationspunkten untereinander 

• Entwicklungsartefakten und Variationspunkten 

oder Varianten 

• Auswahlmöglichkeiten die von der Plattform angeboten werden 

und den Entscheidungen, die bei der Produktentwicklung 

getroffen wurden 


15 


16 

09.07.2009 

8

Grundproblem 

• Grundproblem der Verfolgbarkeit von Variabilität in SPL 

– „Das Problem ist, dass individuelle Features typischerweise nicht 

direkt zu einer individuellen Komponente oder einem Cluster von 

Komponenten verfolgt werden können – das bedeutet, wenn ein 

Produkt durch die Auswahl einer Gruppe von Features definiert 

wird, dann ist eine sorgfältig abgestimmte und komplizierte 

Mixtur an Teilen von verschiedenen Komponenten involviert.“ [4] 

• Beispiel Mobiltelefon 

– Anforderung: Mobiltelefon besitzt einen Internetzugang 

– Komponenten: E-Mail, Browser, Software-Updates, Spiele-Downloaden 

– Anforderungen: Mp3s abspielen, Videos abspielen, Sprachaufzeichnung 

– Komponenten: Mediaplayer 


Grundproblem 

• Grundproblem der Verfolgbarkeit von Variabilität in SPL 

– „Das Problem ist, dass individuelle Features typischerweise nicht 

direkt zu einer individuellen Komponente oder einem Cluster von 

Komponenten verfolgt werden können – das bedeutet, wenn ein 

Produkt durch die Auswahl einer Gruppe von Features definiert 

wird, dann ist eine sorgfältig abgestimmte und komplizierte 

Mixtur an Teilen von verschiedenen Komponenten involviert.“ [4] 

1 

Feature 

1..* 1..* 1..* 

Anforderung Designelement 

1..* 1..* 1..* 1..* 


1..* 

1..* 

Implementierungselement 

17 


18 

09.07.2009 

9

Problemraum 

Problem- und Lösungsraum 

• Die Entwicklungsphasen einer Software-Produktlinienentwicklung 

lassen sich in den Problemraum und Lösungsraum 

einteilen 

• Problemraum 

– Die Systemspezifikation, die während der Anforderungsanalysephase 

und Designanalysephase entwickelt wird 

• Lösungsraum 

– Das konkrete System, welches während der Architektur-, Design- und 

Implementierungsphase erstellt wird 

Anforderungen Design-Analyse Architektur Design Implementierung 


Artefakte im 

Problemraum 

1..* 

1..* 

Artefakte im 

Lösungsraum 

Anforderung: 

Mobiltelefon besitzt einen Internetzugang 

Problemraum 

Grundproblem 

Lösungsraum 


Komponenten: 

E-Mail, Browser, Software-Updates, Spiele-Downloaden 


19 

Lösungsraum 

20 

09.07.2009 

10

Artefakte im 

Problemraum 

1..* 

1..* 

Artefakte im 

Lösungsraum 

Anforderungen: 

Mp3s abspielen, Videos abspielen, Sprache 

aufzeichnen 

Problemraum 


• Zwischenschicht 

Artefakte im 

Problemraum 

1..* 

1..* 

Artefakte im 

Lösungsraum 

Komponente: 

Mediaplayer 

Grundproblem 

Lösungsraum 

Grundproblem und Lösungsansatz 

Artefakte im 

Problemraum 

? 

1..* 

1 

1 

1..* 

Artefakte im 

Lösungsraum 


– Löst n-zu-n Beziehung auf 

– Ermöglicht 1-zu-1 Mapping zwischen Variationspunkten der 

verschiedenen Räume 


21 

22 

09.07.2009 

11

Lösungsansätze 

• Lösungsansätze – Verfolgbarkeit von Variabilität in SPL 

Plattform 

– Unterschiede im Grad der Abdeckung der Entwicklungsphasen 

• Nur eine Phase, mehrere Phasen oder alle Phasen 

Plattform 

Analyse 

Plattform 

Design 

– Unterschiede in der Notation, Notationsabhängigkeit, Ausgangslage 

• Vorstellung der Lösungsansätze von 

– Schmid und John [7] 

– Berg, Bishop und Muthig [1] 

Plattform 



• Schmid et al. 


Ansatz von Schmid et al. 

– „ein homogenes Variabilitätsmanagement über die verschiedenen 

Entwicklungs-Lebenszyklus-Phasen, unabhängig von einer spezifischen 

Notation“ [7] 

• Ausgangslage 

– Einzelsystementwicklung wird betrieben 

– Umstellung auf eine Produktlinienentwicklung 

• Vorgehen 

– Möglichst viele bestehende Notationen, Ansätze und Prozesse behalten 

• Anforderungen, Spezifikationen, Architekturbeschreibungen, Testfälle 

– Variabilität wird in einem neuen Modell verwaltet 


23 

24 

09.07.2009 

12

• Fünf Komponenten des Ansatzes 

Komponenten des Ansatzes 

1. Entscheidungsmodell 

• Basis für die Charakterisierung der Auswirkungen von Variabilität 

• Zentrale Komponente des Ansatzes 

• Zwischenschicht zwischen Problem- und Lösungsraum 

2. Interaktionen 

• Ein Mechanismus, um Interaktionen zwischen verschiedenen 

Entscheidungen (decisions) zu beschreiben 

3. Relationen 

• Relationen zwischen Variationspunkten und spezifischen Entscheidungen 

(Gruppe von Entscheidungen), von denen die Auflösung der Variabilität 

abhängt 

– AND, OR, XOR / sub, #, in, ->, 


• Fünf Komponenten des Ansatzes 

Komponenten des Ansatzes 

4. Auswahltypen 

• Variabilitäts-Auswahltypen 

– optional, alternativ, Mengen-alternativ, Mengen-auswahl, Wert-Referenz 

5. Mapping 

• Mapping / Zuordnung der Auswahltypen auf eine spezifischen Notation 

• Ausdrücken der Variationspunkte in den Entwicklungsartefakten 

• Verfolgbarkeit von Variabilität 

Entscheidungsmodell 

Mapping 


25 

26 

09.07.2009 

13

Variabilitätsmanagement 

- 

Ansatz 

Text-basiert 

ARIS-basiert 

UML-basiert 

feste Elemente des Ansatzes 





Ansatz von Schmid et al. 

Interaktionen Relationen Auswahltypen 





• Entscheidungsmodell nach Schmid et al. 

– Wird in Tabellenform notiert 

– Besteht aus Entscheidungsvariablen 


… 


anpassbare Elemente 

spezifisches 


Text-Mapping 

Model- 


UML-Mapping 



27 

28 

09.07.2009 

14

• Spezifisches Mapping nach Schmid et al. 

Spezifisches Mapping 

– Entscheidungsvariablen werden in die Entwicklungsartefakte integriert 

– Beispiel: textbasiertes Entwicklungsartefakt 



Einbindung des Entscheidungsmodells 

• Entscheidungsmodell als Basis der Variabilität 

– Entscheidungsvariablen können in allen 

Entwicklungsartefakten wiederverwendet werden 

• Produkterstellung 


Anforderungen 

Design Analyse 

Architektur 

Design 

– Entscheidungen treffen 

– Den Entscheidungsvariablen im Entscheidungsmodell 

werden Werte zuweisen 

– Die Variationspunkte in den Entwicklungsartefakten, die mit den 

Entscheidungsvariablen in Bezug stehen, werden instanziiert 



29 

30 

09.07.2009 

15

Verfolgbarkeit 

• Variationspunktinformationen werden im Entscheidungsmodell 

in Form von Entscheidungsvariablen gekapselt 

– Für jeden Variationspunkt in jedem Entwicklungsartefakt 

– Insbesondere die Beziehungen und Abhängigkeiten zu Variationspunkten 

in anderen Artefakten 

• Mithilfe der Entscheidungsvariablen ist eine Verfolgbarkeit der 

Variabilität gewährleistet 

1-zu-1 Mapping zwischen Variationspunkten aus 

dem Problem- und dem Lösungsraum ist möglich 


• Berg et al. 

Ansatz von Berg, Bishop, Muthig 

– „Variabilitätsmanagement in einer dritten Dimension, in einem 

sogenannten konzeptionellen Variabilitätsmodell 

(conceptual variability model)“[1] 

• Ausgangslage 

– Es besteht bereits eine Software-Produktlinienentwicklung 

– Diese soll um ein Variabilitätsmanagement erweitert werden 

• Vorgehen 

– Softwareentwicklung wird in zwei Dimensionen aufgefasst, eine für 

den Entwicklungsprozess und eine für die Abstraktionsebene 

– Variabilität wird in einer 3. Dimension verwaltet 


31 

32 

09.07.2009 

16

Variabilitätsinformationen 

Problemraum 

Anforderungen 

Variabilität 

Design-Analyse 

hohe Abstraktion 

niedrige Abstraktion 

Architektur 


Variabilitätsinformationen 

Problemraum 

einfache Entscheidung 

Anforderungen 

Vp 

Variationspunkt 

(Entscheidungen) 

Variabilität 

Design-Analyse 

hohe Abstraktion 

niedrige Abstraktion 

Vp 

Architektur 

Vp 


Vp 

Zwei Dimensionen 

Design 

3. Dimensionen 

Design 

Vp 


Lösungsraum 



Vp 

Vp 

33 

Lösungsraum 


34 

09.07.2009 

17

Verfolgbarkeit 

• Variationspunktinformationen werden im konzeptionellen 

Variabilitätsmodell gekapselt 

– Für jedes generische Artefakt 

– Insbesondere die Beziehungen und Abhängigkeiten zu Variationspunkten 

in anderen Artefakten 

• Mithilfe dieser gekapselten Variabilitätsinformationen ist eine 

Verfolgbarkeit der Variabilität gewährleistet 

1-zu-1 Mapping zwischen Variationspunkten aus 

dem Problem- und dem Lösungsraum ist möglich 


• Gemeinsamkeiten 

Vergleich der vorgestellten Ansätze 

– Idee für die Verfolgbarkeit von Variabilität ist grundsätzlich dieselbe 

– Variabilitätsinformationen werden gekapselt 

– Gekapselte Informationen ermöglichen die Verfolgbarkeit 

• Unterschiede 

– Voraussetzungen 

– Verständnis der Modelle 

• Entscheidungsmodell 

• Konzeptionelles Variabilitätsmodell 


35 

36 

09.07.2009 

18

• Vorteile 

Vergleich der vorgestellten Ansätze 

– Verfolgbarkeit von Variabilität möglich, über den gesamten 

Entwicklungszyklus 

– Kapselung der Variabilitätsinformationen 

– Notationsunabhängig 

• Nachteile 

– Übersichtlichkeit bei der Auswahl eines konkreten Produktes sehr 

eingeschränkt 

– Keine Angaben zu einer möglichen Visualisierung der Variabilität 


• Zusammenfassung 

Zusammenfassung und Ausblick 

– Grundproblem der Verfolgbarkeit von Variabilität in SPL dargestellt 

– Verschiedene Lösungsansätze vorgestellt und verglichen 

– Vorgestellten Lösungsansätze sind zum Teil in der Praxis erprobt 

• Problem grundsätzlich gelöst 

• Einige Schwächen 

• Ausblick 

– Unterstützung durch Tools ist eingeschränkt 

• Viele verschiedene Tools für Teilbereiche vorhanden 

• Durchgängiges Tool für alle Entwicklungsphasen fehlt noch 


37 

38 

09.07.2009 

19

Fragen & Antworten 

Gerne beantworte ich eure Fragen! 


Literatur 

1. Berg, K., Bishop, J., Muthig, D.: Tracing Software Product Line Variability: From Problem 

to Solution Space. In: Proceedings of SAICSIT 2005, ACM International Conference 

Proceeding Series, vol. 150, pp. 182--191. White River, South Africa (2005) 

2. Berg, K., Muthig, D.: A Critical Analysis of Using Feature Models for Variability Management. 

Technical Report, University of Pretoria, South Africa (2005) 

3. Boehm, B.W.: Guidelines for Verifying and Validating Software Requirements and De-sign 

Specification. In: EURO IFIP 1979, pp. 711--719 (1979) 

4. Griss, D., Allen, R., d’Allesandro, M.: Integrating Feature Modelling with the RSEB. In: 

Proceedings of the 5th International Conference of Software Reuse (ICSR) 1998, pp. 76-- 

85, IEEE Computer Society, Washington, DC, USA (1998) 

5. Pohl, K., Böckle, G., Linden, F.v.: Software Product Line Engineering: Foundations, 

Principles, and Techniques, Springer, Heidelberg (2005) 

6. Riebisch, M.: Towards a More Precise Definition of Feature Models. In: Workshop at 

ECOOP 2003. Pp. 64--76, Books On Demand, Darmstadt (2003) 

7. Schmid, K., John, I.: A customizable approach to full-life cycle variability management. 

Science of Computer Programming, vol. 53, No. 3, pp. 259--284 (2004) 

39 

40 

09.07.2009 

20

• Feature 

Definitionen: „Feature“ 

– „eine funktionale Einheit, die einem System hinzugefügt oder aus 

einem System weggelassen werden kann“ (Plath et al. [9]) 

– “eine für den Endbenutzer sichtbare Charakteristik eines Systems” 

(Czarnecki & Eisenecker [10]) 

– “eine unterscheidbare Charakteristik eines Konzeptes” (STARS [12]) 

– “eine für den Benutzer bedeutender oder markanter, sichtbarer Aspekt, 

Qualität oder Charakteristik eines Software-Systems oder Systems“ 

(Kang et al. [11]) 

– … 

Im Allgemeinen werden als Feature markante und wichtige 

Charakteristiken einer Domäne oder eines Software-Systems 

verstanden (Von der Maßen[8]) 

Definitionen: „Feature“ - Literatur 

8. Maßen, T.v.: Feature-basierte Modellierung und Analyse von Variabilität in Produktlinienanforderungen. 

Dissertation, RWTH Aachen, Shaker, Aachen (2007) 

9. Plath, M.C., Ryan, M.D.: Feature Integration Using a Feature Construct. Science of Computer 

Programming, vol. 41, pp. 53--84, Elsevier, Niederlande (2001) 

10. Czarnecki, K., Eisenecker, U.W.: Generative Programming: Methods, Tools, and Applications. 

Addison-Wesley. Boston, USA (2000) 

11. Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, S.: Feature-Oriented Domain Analysis 

(FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, 

Carnegie Mellon University, Pittsburgh, USA (1990) 

12. Software Technology for Adaptable, Reliable Systems (STARS): Organization Domain Modeling 

(ODM) Guidebook, Technical Report STARS-VCA025/ 001/00 (1996) 

41 

42 

09.07.2009 

21

Verfolgbarkeit von Variabilität in Software-Produktlinine

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?