On the notion of Variability in Software Product Lines

Slides:



Advertisements
Similar presentations
Introduction to Object Orientation System Analysis and Design
Advertisements

Chapter 13 Application Framework. Outline Definition & anatomy Fulfilling the framework contract Building frameworks Examples.
.NET Technology. Introduction Overview of.NET What.NET means for Developers, Users and Businesses Two.NET Research Projects:.NET Generics AsmL.
Construction process lasts until coding and testing is completed consists of design and implementation reasons for this phase –analysis model is not sufficiently.
1 © Wolfgang Pelz UML3 UML 3 Notations describe how to use reusable software. Package Component Deployment Node.
Object Oriented System Development with VB .NET
1 CS1001 Lecture Overview Object Oriented Design Object Oriented Design.
PolymorphismCS-2303, C-Term Polymorphism Hugh C. Lauer Adjunct Professor (Slides include materials from The C Programming Language, 2 nd edition,
1 An Introduction to Visual Basic Objectives Explain the history of programming languages Define the terminology used in object-oriented programming.
Course Instructor: Aisha Azeem
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
ACM/JETT Workshop - August 4-5, 2005 UML Modeling using MagicDraw UML for Java Programmers.
Domain-Specific Software Engineering Alex Adamec.
Proceso kintamybių modeliavimas Modelling process variabilities Donatas Čiukšys.
University of Palestine Department of Information Technology Done by: Montaser El sabea Supervisors: yassmen El Bobo Unified Modeling Language.
Microsoft Visual Basic 2005: Reloaded Second Edition
Object-oriented Software Engineering with Reuse Contracts Koen De Hondt, Carine Lucas, Kim Mens, Tom Mens, Patrick Steyaert, Roel Wuyts Programming Technology.
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
An Introduction to Software Architecture
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
The Software Product Line Architectures
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Android for Java Developers Denver Java Users Group Jan 11, Mike
1 Introduction to Software Engineering Lecture 1.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
Chapter 1 The Systems Development Environment Modern Systems Analysis and Design Fifth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
CIS 112 Exam Review. Exam Content 100 questions valued at 1 point each 100 questions valued at 1 point each 100 points total 100 points total 10 each.
 All calls to method toString and earnings are resolved at execution time, based on the type of the object to which currentEmployee refers.  Known as.
Software Product Lines Peter Bell CEO/CTO, SystemsForge cf.Objective() 2008 Peter Bell CEO/CTO, SystemsForge cf.Objective() 2008.
Object Oriented Programming
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
The Systems Development Environment Systems Analysis and Design II.
CSC 480 Software Engineering High Level Design. Topics Architectural Design Overview of Distributed Architectures User Interface Design Guidelines.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Java Programming, Second Edition Chapter Twelve Advanced Inheritance Concepts.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Using Bayesian Belief Networks in Assessing Software Architectures Jilles van Gurp & Jan Bosch.
Design and implementation Chapter 7 – Lecture 1. Design and implementation Software design and implementation is the stage in the software engineering.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
L5 - February 22, 2006copyright Thomas Pole , all rights reserved 1 Lecture 5: Graphically Based Code Generation and Text Chapter 4: Paradigm.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Managing Qualitative Knowledge in Software Architecture Assesment Jilles van Gurp & Jan Bosch Högskolan Karlskrona/Ronneby in Sweden Department of Software.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
Review of last class Software Engineering Modeling Problem Solving
Design Patterns: MORE Examples
CompSci 280 S Introduction to Software Development
Software Prototyping.
INF230 Basics in C# Programming
Roberta Roth, Alan Dennis, and Barbara Haley Wixom
The Movement To Objects
Object-Oriented Analysis and Design
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Low Budget Productions, LLC
Systems Analysis and Design With UML 2
Recall The Team Skills Analyzing the Problem (with 5 steps)
Names, Binding, and Scope
Chapter 20 Object-Oriented Analysis and Design
Appendix A Object-Oriented Analysis and Design
Variability in Software Systems The Key to Software Reuse
Design Tips.
Analysis models and design models
Software Design Lecture : 14.
Polymorphism Professor Hugh C. Lauer CS-2303, System Programming Concepts (Slides include materials from The C Programming Language, 2nd edition, by Kernighan.
An Introduction to Software Architecture
Chapter 7 –Implementation Issues
CS310 Software Engineering Lecturer Dr.Doaa Sami
Chapter 5 Architectural Design.
From Use Cases to Implementation
Presentation transcript:

On the notion of Variability in Software Product Lines Jilles van Gurp Jan Bosch Mikael Svahnberg

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

Contents What and why Variation points Features Managing Variability Concluding remarks 16/04/2019 http://segroup.cs.rug.nl

Development = constraining variability 16/04/2019 http://segroup.cs.rug.nl

So, what is variability? 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 16/04/2019 http://segroup.cs.rug.nl

Why do we need variability? 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 16/04/2019 http://segroup.cs.rug.nl

Variability is needed for reuse More variability in software More supported contexts More reusable software! SPLs are all about reusing software assets 16/04/2019 http://segroup.cs.rug.nl

How much variability do we need? Just enough, not more, not less Variation points increase complexity 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 cost changes lots of variation no variation That’s what we want in a SPL 16/04/2019 http://segroup.cs.rug.nl

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

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

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

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 16/04/2019 http://segroup.cs.rug.nl

Variability Realization Techniques Binding-time Example Variation point Inheritance Implementation GUI Components Abstract class Plugins Link-time / Run-time (language dep.) Winamp visualization plugin Interface Parameters Application startup Xterm parameters A variable #define Compilation Support for different platforms Preprocessor directive Mention Mikael Svahnberg’s article about variability realization techniques 16/04/2019 http://segroup.cs.rug.nl

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 16/04/2019 http://segroup.cs.rug.nl

Unit of incrementation as systems evolve [gibson] Feature A logical unit of behavior that is specified by a set of functional and quality requirements [bosch] Unit of incrementation as systems evolve [gibson] Gibson: Feature Requirements Models: Understanding Interactions 16/04/2019 http://segroup.cs.rug.nl

Features and Variability 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 16/04/2019 http://segroup.cs.rug.nl

Managing Variability Find the variation points early Constrain the variation points Select the appropriate technique for implementing Manage the variants 16/04/2019 http://segroup.cs.rug.nl

Feature Diagrams Can be used to model features and the relations between them Can be used to trace features Can be used to model variability 16/04/2019 http://segroup.cs.rug.nl

Example Feature Diagram 16/04/2019 http://segroup.cs.rug.nl

Patterns of Variability 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 POP3 account and an IMAP account simultaneously 16/04/2019 http://segroup.cs.rug.nl

Example 1, single variant Designed during AD Bound at run-time Open at run-time 16/04/2019 http://segroup.cs.rug.nl

Example 2, optional variant Introduced during AD Bound at link time Open at link time (= run-time) 16/04/2019 http://segroup.cs.rug.nl

Example 3, multiple parallel variants Introduced during AD Bound at run-time Open during DD 16/04/2019 http://segroup.cs.rug.nl

Example 4, optional single variant Introduced during AD Open at run-time Bound at run-time 16/04/2019 http://segroup.cs.rug.nl

Trends in variability 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 and used right away refer to funnel diagram at the beginning 16/04/2019 http://segroup.cs.rug.nl

Why run-time variability? Going through the edit/compile/debug/deploy cycle is expensive It is convenient for end users Because we can! 16/04/2019 http://segroup.cs.rug.nl

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

Related Work Recent work Bachmann & Bass Clauss (improved UML notation) Upcoming feature modeling workshop at GCSE 16/04/2019 http://segroup.cs.rug.nl

Our Contributions Terminology Patterns of variability Makes discussions about variability to the point Patterns of variability Extensions to the feature diagram notation Enables communicating variability Methodology for managing variability 16/04/2019 http://segroup.cs.rug.nl

Future work 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 16/04/2019 http://segroup.cs.rug.nl

Contact information jilles@cs.rug.nl jan.bosch@cs.rug.nl mikael.svahnberg@bth.se http://segroup.cs.rug.nl/ Contact info More publications Personal homepages Mailing list 16/04/2019 http://segroup.cs.rug.nl