Software Product Lines, Study notes of Architecture

Download Software Product Lines and more Study notes Architecture in PDF only on Docsity!

Software Product Lines

Software Product Line Engineering and Architectures

Bodo Igler and Burkhardt Renz Hochschule Rhein-Main and Technische Hochschule Mittelhessen Wintersemester 2020/

Questions

How can you produce many different but related software products? (mass production) How can you do this, if you have to satisfy special customer requirements? (customization) if the products have to be cheap and good? (cost efficieny, quality) if you have to react quickly to changing requirements? (time to market)

Answer: Adopt a Software Product Line Approach.

Overview

Introduction Examples Terminology Approach

Commonality and Variability Motivation Commonality and Variability Analysis Features

Putting Things Together Architecture The Big Picture Conclusion

Example

Car Manufacturing

Example

Integrated Development Environment

Software Product Lines

Software Platform

set of software subsystems and interfaces common structure facilitates efficient development and production of derivative products comprises several artifacts code architecture requirements manuals test cases

...

Software Product Line Engineering

Software Product Line

A software product line is a set of software-intensive sys- tems sharing a common, managed set of features that sat- isfy needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. –Paul Clements, Linda Northrop

Software Product Line Engineering

develop family of software applications apply mass customization use software platform

Domain Engineering

Results

definition of commonality “What is common to all products?” definition of variability “What is different? What is allowed to vary?” “How does it vary? How is it allowed to vary?” ⇒ platform = reusable artifacts ( domain artifacts , “skeleton”)

During Each Step

detail variability from previous step add – if necessary – internal variability

Application Engineering

Results

the product ( application artifacts , “skeleton + flesh”) feedback to domain engineering

During Each Step

bind variability of each domain artifact ⇒ obtain application artifacts fill in templates implement interfaces provide configuration files

...

Motivation

Questions: How do I find the appropriate commonalities? How do I find the appropriate variability? Answer: Commonality and Variability Analysis.

Question: How do I document commonalities and variability? Answer: Feature Model.

General Idea

Input

variants of one product = product family (Parnas 1976)

Process

(^1) Commonality Analysis: find commonalities categorize commonalities (^2) Variability Analysis: find special properties categorize special properties

Output

appropriate abstraction

Terminology

(Positive) Variability

common degree of freedom

Negative Variability

a degree of freedom is violated under certain circumstances

External Variability

required by and/or visible to customer

Internal Variability

neither required by nor visible to customer

Terminology

Variation Point

something that varies, a degree of freedom e.g. color, payment method

Variant

potential property of something that varies e.g. “red”, “green” or “credit card”, “cash”

Binding

fix a variation point by specifying/instantiating a (legal) variant

Binding Time

e.g. design, coding, compilation, installation, run-time

Features

Feature

“end-user visible characteristic of a system”

Composed Feature

composition of sub-features

Atomic Feature

cannot be divided into sub-features

Feature Model Requirements

A Feature Model is

to represent all features to represent the relationships between features to distinguish between commonality and variability to be independent of implementation technology to be suitable during requirements engineering, design, code and test