1. John D. McGregor C15 – Variation in architecture
CPSC 875
John D. McGregor
C15 – Variation in architecture

3. Goal
The goal of variability in a software product line is to maximize return on investment (ROI) for building and maintaining products over a specified period of time or number of products.

4. Different kinds of product variation
Differentiation
Evolution
There is also data variation

5. Management of variation

6. Software Product Line
Multiple products, each a bit different from the others
The differences are encapsulated in variation points
A variation point is not a single location in the code
Corresponds to a subset of the requirements

7. Variation mechanisms
An instance of the architecture resolves certain variations
Mechanisms
One system definition extends another
A system definition is included or excluded
Subprograms have parameters

8. Binding time
The reason that some variation is not resolved is because the binding time for the variation is after architecture instantiation time
The binding time is partially determined by the architect
To do this
Who will do the binding?
When do they touch the system?
For example, a marketing person decides a feature is included – can only happen at requirements time

9. Eliminating variability
Some apparent variability can be reduced to commonality
A standard interface can be placed between the commonality and the apparent variability with the result that we don’t care what is on the other side of the interface. The BlueTooth interface for example.

10. USB state machine from standard spec
We do worry about conformance
of the architecture to abstract
specifications such as standards.

11. Vehicle variations Powertrain Infotainment Transmissions Engines
Radios
Information package
GPS/navigation
Entertainment package

12. But what about variations in quality attribute levels?
One product needs to be airworthy certified but others do not
One needs real-time performance another does not
One must be secure another one does not

13. What to do?
Would you
Make everything meet the toughest standard?
Re-implement all the assets?
Tactic: reduce and isolate – encapsulate the section that differs among products; refactor when possible to reduce the area; hide behind interfaces

14. Use cross cutting techniques
Aspects as we have already discussed cut across the system decomposition
Other language idioms such as “mix-ins” also cross cut
Look for a technique where fragments are maintained separately

15. Feature model

16. Configuration editor

19. SimpleControlSystem Family
A product line project structure
3 levels of architecture
Ref, Obj, Sys
AADL/ALISA at each level
The ALISA “for” statement ties the ALISA file to the AADL file
The “extends” and “refines to” ties two AADL files together

20. Multi-threaded design/programming

21. Complexity

22. Here is what you are going to do
Expand your project to a software product line with at least 3 products
Use featureIDE to examine the features of your products
Use ALISA requirements to describe the variations.
Give a brief text description of what changes in the AADL model.
DUE: April 3rd by 11:59PM