SEGROUP On the notion of Variability in Software

SEGROUP On the notion of Variability in Software Product Lines Jilles van Gurp Jan Bosch Mikael Svahnberg http: //segroup. cs. rug. nl

SEGROUP, University of Groningen Frameworks ü http: //segroup. cs. rug. nl/ SPLs ü Founded August 2000 ü Before that we were known as RISE, University of Karlskrona/Ronneby, Sweden ü Third author is still in Sweden SOC Software Architecture 6/17/2021 http: //segroup. cs. rug. nl 2

Contents SEGROUP ü What and why ü Variation points ü Features ü Managing Variability ü Concluding remarks 6/17/2021 http: //segroup. cs. rug. nl 3

SEGROUP Development = constraining variability 6/17/2021 http: //segroup. cs. rug. nl 4

So, what is variability? SEGROUP ü Variability is a delayed design decision ü Rather than specifying now, you allow for choice later ü Variability is relevant throughout the development process, including run-time 6/17/2021 http: //segroup. cs. rug. nl 5

Why do we need variability? SEGROUP ü Reuse = using an existing piece of software in a different context ü Reuse requires that the reused software adapts to the new context ü Software without variability is not reusable ü Opportunistic reuse does not work, the software needs to be prepared for reuse ü So, reuse requires variability 6/17/2021 http: //segroup. cs. rug. nl 6

Variability is needed for reuse SEGROUP More variability in software More supported contexts More reusable software! SPLs are all about reusing software assets 6/17/2021 http: //segroup. cs. rug. nl 7

SEGROUP How much variability do we need? ü Just enough, not more, not less ü Variation points increase complexity That’s what we want in a SPL lots of variation cost – So, too much variability increases the cost of software ü Variation is needed to meet future requirements – So, too little variability makes meeting those requirements expensive 6/17/2021 http: //segroup. cs. rug. nl no variation changes 8

Variation point SEGROUP if statement . o file idl interface A concrete point in one of the representations of the software where variants of an entity can be inserted. property abstract class #define 6/17/2021 http: //segroup. cs. rug. nl 9

Variation point stages SEGROUP Implicit Designed Introduce variation point & variants Bound Select Variant i. e. create an abstract description of the variants and specify the variants (can be done later) 6/17/2021 http: //segroup. cs. rug. nl 10

Example SEGROUP During requirement specification the need is identified to draw multiple graphical widgets on the screen Designed During the design an abstact widget class is introduced and several subclasses During implementation a widget subclass (e. g. a button) is instantiated and used. 6/17/2021 Implicit http: //segroup. cs. rug. nl Bound 11

SEGROUP Adding variants to a variation point ü Open/closed variation points ü Variants can be added in specific representations only. – E. g. you can’t add subclasses in the requirements specification. Nor can you do so in an executing program (unless you have dynamic linking). But you can add subclasses in the source code 6/17/2021 http: //segroup. cs. rug. nl 12

Variability Realization Techniques SEGROUP Technique Binding-time Example Variation point Inheritance Implementation GUI Components Abstract class Plugins Link-time / Run-time Winamp (language dep. ) visualization plugin Interface Parameters Application startup Xterm parameters A variable #define Compilation Support for different platforms Preprocessor directive 6/17/2021 http: //segroup. cs. rug. nl 13

SEGROUP When is the best time to introduce variability? ü Before you have invested in assets that need to be redesigned if you introduce variation ü I. e. before you design the system 6/17/2021 http: //segroup. cs. rug. nl 14

Feature SEGROUP A logical unit of behavior that is specified by a set of functional and quality requirements [bosch] Unit of incrementation as systems evolve [gibson] 6/17/2021 http: //segroup. cs. rug. nl 15

Features and Variability SEGROUP ü Feature = unit of change ü Variation = allowing for change ü Variation can be described in terms of features ü Features are typically specified early ü Variation points need to be identified early 6/17/2021 http: //segroup. cs. rug. nl 16

Managing Variability SEGROUP ü Find the variation points early ü Constrain the variation points ü Select the appropriate technique for implementing ü Manage the variants 6/17/2021 http: //segroup. cs. rug. nl 17

Feature Diagrams SEGROUP ü Can be used to model features and the relations between them ü Can be used to trace features ü Can be used to model variability 6/17/2021 http: //segroup. cs. rug. nl 18

Example Feature Diagram SEGROUP 6/17/2021 http: //segroup. cs. rug. nl 19

Patterns of Variability SEGROUP ü Variation point = specialization ü Three types: – 0 or 1 variant = optional variant – E. g. printing debug information – 1 out of n variants = single variant (xor) – E. g. a background picture on your desktop – m out of n variants = multiple parallel variants (or) – E. g. retrieving email from a POP 3 account and an IMAP account simultaneously 6/17/2021 http: //segroup. cs. rug. nl 20

Example 1, single variant SEGROUP • Designed during AD • Bound at run-time • Open at run-time 6/17/2021 http: //segroup. cs. rug. nl 21

Example 2, optional variant SEGROUP • Introduced during AD • Bound at link time • Open at link time (= run-time) 6/17/2021 http: //segroup. cs. rug. nl 22

SEGROUP Example 3, multiple parallel variants • Introduced during AD • Bound at run-time • Open during DD 6/17/2021 http: //segroup. cs. rug. nl 23

SEGROUP Example 4, optional single variant • Introduced during AD • Open at run-time • Bound at run-time 6/17/2021 http: //segroup. cs. rug. nl 24

Trends in variability SEGROUP ü Variation points are increasingly open and bound at run-time • E. g. MS media player can download and use new codecs without even restarting the application ü Going from static to dynamic linking has been a major push in doing so • E. g. DLLs can be upgraded separately from the apps that use it • E. g. jar files can be downloaded on demand used right away 6/17/2021 http: //segroup. cs. rug. nl 25

Why run-time variability? SEGROUP ü Going through the edit/compile/debug/deploy cycle is expensive ü It is convenient for end users ü Because we can! 6/17/2021 http: //segroup. cs. rug. nl 26

Variation management process SEGROUP Make Feature Diagram For each variation point: • Abstraction level Select Realization Technique + variant management technique (e. g. manual or automatic) • Assess binding time • When it’s open Add variants Bind 6/17/2021 http: //segroup. cs. rug. nl 27

Related Work SEGROUP ü Recent work – Bachmann & Bass – Clauss (improved UML notation) – Upcoming feature modeling workshop at GCSE 6/17/2021 http: //segroup. cs. rug. nl 28

Our Contributions SEGROUP ü Terminology • Makes discussions about variability to the point ü Patterns of variability ü Extensions to the feature diagram notation • Enables communicating variability ü Methodology for managing variability 6/17/2021 http: //segroup. cs. rug. nl 29

Future work SEGROUP ü Integrate with UML (people are already working on this) • Trace variation points in e. g. use case diagrams or collaboration diagrams or even source code • Tool support ü Further develop methodology and best practices • Our method can be used as a starting point ü Taxonomy of variability realization techniques • Mikael Svahnberg ü Validation. E. g. case studies. • One of my colleagues is working on this ü Late variability techniques • E. g. Separation of Concerns, AOP, SOP, MDSOC 6/17/2021 http: //segroup. cs. rug. nl 30

Contact information SEGROUP jilles@cs. rug. nl jan. bosch@cs. rug. nl mikael. svahnberg@bth. se • Contact info • More publications • Personal homepages • Mailing list 6/17/2021 http: //segroup. cs. rug. nl 31