• Keine Ergebnisse gefunden

Software Product Line Engineering

N/A
N/A
Protected

Academic year: 2022

Aktie "Software Product Line Engineering"

Copied!
12
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

Software Product Line Engineering

Lab Class 3

(2)

Outline

• Presentation Assignment 2

(3)

Task 1a: Domain and Application Engineering

Domain

Analysis Domain

Design Domain

Implementation Domain Engineering

Requirements Analysis

Application Engineering

Design

Analysis Integration

and Test

domain model architecture(s)

features product configuration

requirementsnew

- domain-specific languages - code generators

- components Custom

Design Custom

Development requirementsnew

customer needs domain knowledge

product

(4)

Task 1b: Waterfall model vs AE/DE

• Classical process models are

linear, focus on product delivery.

• AE/DE: emphasizing reusability

DE: “[...] 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 newsystems.”

(Czarnecki/Eisenecker: Generative Programming)

Requirements

Design

Implementation Verification

Maintenance

(5)

Task 2a: Observer Pattern

• Behavioral Pattern by the GoF

• Observers can subscribe to a subject.

• Subject can notify observers by

calling update() method https://en.wikipedia.org/wiki/Observer_pattern

(6)

Task 2b: Template Method Pattern

• Behavioral pattern by the GoF

• A template method in an

abstract class uses methods that intentionally

unimplemented.

• A concrete class specifices and provides unimplemented

methods for customization.

AbstractClass + TemplateMethod() +operation1()

+operation2()

ConcreteClass +operation1() +operation2()

...

operation1() operation2() ....

(7)

Task 2c: Strategy Pattern

• Behavioral Pattern by the GoF

• Alternative implementations of an algorithm (concrete

strategies) are hidden between an Strategy interface.

https://www.dofactory.com/net/strategy-design-pattern

(8)

Task 3: Feature Model Extraction

• Options for compression

Check (crc32, crc64, sha256), MatchFinder (bt2, bt3, bt4, hc3, hc4), MemoryLimit, Nice, Depth, Dict, Dist, BlockSize, Threads,

PositionBits, Lc, Lp, FlushTimeout, ...

• Cross-tree constraints

lc + lp ≤ 4

bt2 nice ≥ 2

(hc3 bt3) nice ≥ 3

(hc4 bt4) nice ≥ 4

(9)

Logger - timestamp() +log(String) +saveLogU()

FilLogger +saveLog()

NetworkLogger +saveLog()

Switch Rot13

Observer Pattern

Template Method

tegy Pattern

Subject

Concrete Observers Observer

Context

Strategy

Concrete Strategies

(10)

Inflexible Extension Mechanism

<<interface>>

Message +setContent() +getContent()

TextMessage

TextMsgDecorator -message

EncryptedMessage ColorMessage

Color

Decorator Pattern

<<interface>>

Message

EncryptedMessage ColorMessage TextMessage

We cannot combine the features

EncryptedColorMessage

(11)

Task 4: Feature Modeling

a) Feature diagrams are easier to comprehend and communicate.

b) Product Line A ...

i. Valid configurations: ACD, ACE, ACDB, ACEB

ii. Naive solution: Create all combinations {0, 1}{A, B, ...} , validate each one, retain only valid ones.

iii. A (B A) (C A) [((D E)) C ¬(D E)]

iv. The implication E B reduces the number of valid configurations: ACE becomes invalid

v. (E B) cannot be modeled as an optional feature, but as a cross-tree constraint.

E

E B

(12)

Task 4c-e)

Referenzen

ÄHNLICHE DOKUMENTE

 Modules can be composed within a new context of another project (variability).. Design Patterns for Variability.. Observer Pattern. “Define[s] a one-to-many dependency

Software Product Line Engineering.. Lab

 Make feature explicit in source

 Interactions between features are an important variability problem of software product lines.  Dynamic interactions are hard

• No feature traceability leads to code scattering, replication and tangling.. 2) Library Scaling Problem (Components). • Limited scalability due to

Generative programming (GP) is a style of computer programming that uses automated source code creation through generic classes, prototypes, templates, aspects, and code generators

The ability to extend programming languages with domain specific concepts, mix programs (i.e. descriptions written in general purpose languages) and models (i.e. descriptions

To this end, we (1) inte- grate feature modelling and AOP to structure the SPL implementation to facilitate product derivation and (2) define a model-driven product derivation