Software Product Line (SPL) engineering is a paradigm shift towards modeling and developing software system families rather than individual systems. It focuses on the means of efficiently producing and maintaining multiple similar software products, exploiting what they have in common and managing what varies among them. This is analogous to what is practiced in the automotive industry, where the focus is on creating a single production line, out of which many customized but similar variations of a car model are produced. Feature models (FMs) are a fundamental formalism for specifying and reasoning about commonality and variability of SPLs. FMs are becoming increasingly complex, handled by several stakeholders or organizations, used to describe features at various levels of abstraction and related in a variety of ways. In different contexts and application domains, maintaining a single large FM is neither feasible nor desirable. Instead, multiple FMs are now used. In this thesis, we develop theoretical foundations and practical support for managing multiple FMs. We design and develop a set of composition and decomposition operators (aggregate, merge, slice) for supporting separation of concerns. The operators are formally defined, implemented with a fully automated algorithm and guarantee properties in terms of sets of configurations. We show how the composition and decomposition operators can be combined together or with other reasoning and editing operators to realize complex tasks. We propose a textual language, FAMILIAR (for FeAture Model scrIpt Language for manIpulation and Automatic Reasoning), which provides a practical solution for managing FMs on a large scale. An SPL practitioner can combine the different operators and manipulate a restricted set of concepts (FMs, features, configurations, etc.) using a concise notation and language facilities. FAMILIAR hides implementation details (e.g., solvers) and comes with a development environment. We report various applications of the operators and usages of FAMILIAR in different domains (medical imaging, video surveillance) and for different purposes (scientific workflow design, variability modeling from requirements to runtime, reverse engineering), showing the applicability of both the operators and the supporting language. Without the new capabilities brought by the operators and FAMILIAR, some analysis and reasoning operations would not be made possible in the different case studies. To conclude, we discuss different research perspectives in the medium term (regarding the operators, the language and validation elements) and in the long term (e.g., relationships between FMs and other models).
Exploring the Future Potential of AI-Enabled Smartphone Processors
Acher PhD thesis defense
1. Managing Multiple Feature Models:
Foundations, Language and Applications
PhD candidate: Mathieu Acher
PhD supervisors: Philippe Lahire and Philippe Collet
7. “a set of software- intensive systems that share a common, managed set
of features satisfying the specific needs of a particular market segment
or mission and that are developed from a common set of core assets in a
prescribed way” [Clements et al., 2001]
Software
Product Lines
7
8. Software Product
Line Engineering
Factoring out commonalities
for Reuse [Krueger et al., 1992] [Jacobson et al., 1997]
Managing variabilities
for Software Mass Customization [Bass et al., 1998] [Krueger et al., 2001], [Pohl et al., 2005]
8
9. “Reuse-in-the-large works
best in families of related
systems, and thus is domain
dependent.” [Glass, 2001]
Domain engineering
Domain Analysis Domain Implementation
(problem) (solution)
• elicitate requirements and scope the line
• variability modeling: determine
commonalities and variabilities usually in C++
terms of features
UML
model service
Common assets Variants
Variability Model Reusable Assets
(e.g., models or source code) 9
(Feature Model)
10. Domain engineering (development for reuse)
“central to the software product
Common assets Variants
Feature Model line paradigmReusable Assets
is the modeling
(e.g., models or source code)
and management of variability,
that is, the commonalities and
differences in the applications”
[Pohl et al., 2005]
Feature Configurations
product1 product2
productn
Application engineering (development with reuse) 10
11. Outline
• Towards Multiple Feature Models
– Software Product Line Engineering
– Feature Model
– Issues in Feature Modeling
– Multiple Feature Models: Example
• Applying Separation of Concerns
– Composition
– Decomposition
• Supporting language: FAMILIAR
• Applications
• Conclusion and Perspectives
11
12. Feature Model:
de facto standard for modeling variability
• Central to many software product line approaches
– More than 1000 citations of [Kang et al., 1990] per year
– Generative programming [Czarnecki et al., 2000]
• Research effort
– Formal Semantics [Schobbens et al., 2007] φ
– Automated Reasoning Techniques [Batory et al., 2005], [Czarnecki et al., 2007],
[Mendonca et al., 2009], [Thuem et al., 2009] , [Janota et al., 2010], [Benavides et al., 2010]
• Tools
– Commercial: pure::variants, Gears
– Academic: fmp, FeatureIDE, FaMa, SPLOT, TVL, etc.
12
13. Feature Models
describe the common and variable features
(characteristics) of a system under study
Medical Image
Modality Acquisition
Format Anonymized
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized
DICOM implies Anonymized
PET or Anonymized
13
14. Feature Models
Hierarchy: rooted tree
Variability:
• mandatory,
• optional,
• Groups: exclusive or inclusive features
• Cross-tree constraints
Medical Image
Modality Acquisition
Format Anonymized
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized
DICOM implies Anonymized
PET or Anonymized
14
15. Feature Models
Hierarchy + Variability = set of valid configurations
Medical Image
Modality Acquisition
Format Anonymized
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized
DICOM implies Anonymized
PET or Anonymized
15
16. Feature Models
Hierarchy + Variability = set of valid configurations
Medical Image
Illegal configuration
Modality Acquisition
Format Anonymized
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized see Or-group:
DICOM implies Anonymized
PET or Anonymized at least one feature should be selected
16
17. Feature Models
Hierarchy + Variability = set of valid configurations
Medical Image
Illegal configuration
Modality Acquisition
Format Anonymized
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized see constraint “PET or Anonymized”
DICOM implies Anonymized
PET or Anonymized
17
18. Feature Models
Hierarchy + Variability = set of valid configurations
Medical Image
Satisfiability (NP-complete)
Modality Acquisition
Format Anonymized
Configuration Checking
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized
Dead features detection
DICOM implies Anonymized
PET or Anonymized …
Around 30 reasoning operations
[Schobbens et al., 2007] [Benavides et al., 2010] 18
19. Propositional Feature Models
Hierarchy + Variability = set of valid configurations
Propositional formula (^, v, ~, , =>)
Boolean variables
Medical Image
set of valid assignments
Modality Acquisition
Format Anonymized φ = Medical Image ^
MRI PET DICOM Nifti Format Medical Image^
T1 T2 T1 or T2 excludes Anonymized
DICOM implies Anonymized Anonymized => Medical Image ^
PET or Anonymized
…
[Batory et al., 2005] [Czarnecki et al., 2007] 19
20. Outline
• Towards Multiple Feature Models
– Software Product Line Engineering
– Feature Model
– Issues in Feature Modeling
– Multiple Feature Models: Example
• Applying Separation of Concerns
– Composition
– Decomposition
• Supporting language: FAMILIAR
• Applications
• Conclusion and Perspectives
20
21. Feature models are becoming
large and complex + 5000 features
Constraint
involving 50
features
Scalability issues in terms of
- construction
- evolution
- reasoning 21
22. Multiple Feature Models
SPL/internal/software variability Concern 1, 2, 3, …, n
(Pohl et al. 2005, Metzger 2007)
View 1, 2, 3, …, n
(Dunghana et al. 2010,
Hubaux et al. 2010, Zaid et al. 2010)
constraints
……..
constraints
……..
constraints
……..
constraints
……..
constraints
……..
constraints
……..
constraints
constraints ……..
……..
constraints
……..
constraints constraints
constraints
…….. …….. ……..
context variability
PL/external variability (FORM 1998, Tun et al. 2009 (problem world), Stakeholder 1, 2, 3, …, n
(Pohl et al. 2005, Metzger 2007) Hartmann 2008 (CVM), Lee et al. 2010 (Czarnecki 2005, Reiser et al. 2007,
Hartmann et al. 2009, Classen et al. 2009,
Mendonca et al. 2010)
FAMILIAR 22
23. Outline
• Towards Multiple Feature Models
– Software Product Line Engineering
– Feature Model
– Issues in Feature Modeling
– Multiple Feature Models: Example
• Applying Separation of Concerns
– Composition
– Decomposition
• Supporting language: FAMILIAR
• Applications
• Conclusion and Perspectives
23
24. Case Study: Medical Imaging Services
• Scientists assemble a wide variety of medical imaging
services (algorithms)
– Processing chain to manipulate large medical data sets
Workflow
24
25. (1) Medical imaging services are highly variable
input medical image
Medical Image
output medical image
Medical Image
Modality Acquisition Format Anonymized
MRI CT SPEC PET DICOM Nifti Analyze Modality Acquisition Format
And-Group Xor-Group
T1 T2 Optional Or-Group
MRI CT SPEC PET DICOM Nifti
Mandatory
And-Group Xor-Group
T1 T2 Optional Or-Group
Mandatory
Medical
Imaging
Service
Registration
GridComputingNode
Transformation Method Interactive
Operating System Processor FileSizeLimit Linear Non Grid Spatial Frequency
NetworkProtocol
And-Group Xor-Group
Optional Or-Group
Windows Linux x32 x64 Mandatory
Rotation Scaling Affine
HeaderEncoding
And-Group
Optional
Xor-Group
Or-Group
Format Cryptographic
algorithm methods
Mandatory XML HTTP
And-Group Xor-Group
grid deployment
Optional Or-Group
Mandatory
network protocol variability
25
26. (2) Managing the in the entire workflow
Medical Image
Modality Acquisition
Medical Image Format Anonymized
MRI PET DICOM Nifti
Modality Acquisition T1 or T2 excludes Anonymized
Format Anonymized T1 T2
DICOM implies Anonymized
PET or Anonymized
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized
DICOM implies Anonymized
PET or Anonymized
Medical Image
Modality Acquisition
Format Anonymized
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized Medical Image
DICOM implies Anonymized
PET or Anonymized
Modality Acquisition
Format Anonymized
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized
DICOM implies Anonymized
PET or Anonymized
Medical Image
Modality Acquisition
Format Anonymized
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized
DICOM implies Anonymized
PET or Anonymized
Medical Image
Modality Acquisition
Format Anonymized
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized
DICOM implies Anonymized
PET or Anonymized
Medical Image
Modality Acquisition
Format Anonymized
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized
DICOM implies Anonymized
PET or Anonymized
26
31. Outline
• Towards Multiple Feature Models
– Software Product Line Engineering
– Feature Model
– Issues in Feature Modeling
– Multiple Feature Models: Example
• Applying Separation of Concerns
– Composition
– Decomposition
• Supporting language: FAMILIAR
• Applications
• Conclusion and Perspectives
31
32. Different forms of composition
FMMIsupport
insert
Medical Image
aggregate merge
aggregate FMalgo
Format MI Algorithm
ModalityAcquisition
FMalgo Method Interactive
FMMIsupport.PET implies FMalgo.PAM
MI Algorithm
SPEC PET Name
insert
CT FMMIsupport.CT or FMMIsupport.SPEC implies FMalgo.BAM Model
insert Atlas Method Grid
Non Interactive
FMMIsupport PAM BAM
Model
CFL EMS
Medical Image Medical Image Medical Image
DICOM Nifti Analyze Atlas Non Grid
Medical Image
Input feature modelsPAM
Modality Acquisition
Modality Acquisition Format Anonymized
Modality Acquisition Format Anonymized
Format Anonymized
MRI PET DICOM Nifti
MRI
BAM
PET DICOM Nifti
MRI PET DICOM Nifti
T1 T2 T1 or T2 excludes Anonymized
DICOM implies Anonymized
T1 T2 T1 or T2 excludes Anonymized
PET or Anonymized
T1 or T2 excludes Anonymized DICOM implies Anonymized
T1 T2 PET or Anonymized
PET implies DICOM or Analyze
DICOM implies Anonymized
PET or Anonymized
CFL EMS
Analyze excludes (CT and SPEC)
ModalityAcquisition Format
merge
CT SPEC PET Name Medical Image
Modality Acquisition
Format Anonymized
DICOM
Nifti Analyze
MRI PET DICOM Nifti
Composed feature model
FMMRI PET implies DICOM or Analyze
T1 T2 T1 or T2 excludes Anonymized
DICOM implies Anonymized
PET or Anonymized
FMmdata
Analyze excludes (CT and SPEC) FMalgo1 FMalgo2
MRI
MI Algorithm MI Algorithm
MetaData
Method Method Interactive
Semantics: we characterize composed feature model in terms of
T1 T2
Anonymized Model
Atlas Atlas Non Grid
input sets of configurations CFL EMS
PAM BAM
CFL EMS
input hierarchies
32
35. Merge Union: Availability Checking
∩
Yes!
Can suppliers provide all services?
comparison
see [Thuem et al., 2009]
35
36. How to implement merge operators?
Medical Image Medical Image
MedicaI Image
Anonymized MRI Header
Anonymized MRI DICOM
Anonymized MRI DICOM
T1 T2
T1 T2
<<requires>> T1 T2
φ1 φ2 φ3
Medical Image
φ123
+
Anonymized MRI Header DICOM
T1 T2
merged propositional formula
merged hierarchy
Medical Image
Set mandatory features
Detect Xor and Or-groups Anonymized MRI Header DICOM
Compute “implies/excludes” Header excludes DICOM
constraints T1 T2 Header implies Anonymized
Anonymized v Header v ~DICOM v ~T1 v ~T2
Anonymized v Header v DICOM v ~T1 v ~T2 36
[Czarnecki et al., 2007], [She et al., 2011]
37. Contributions
– Well-defined semantics
– Guarantee semantics properties by construction
– More compact feature models than reference-based
techniques [Schobbens et al., 2007], [Hartmann et al., 2007]
• Easier to understand
• Easier to analyze (e.g., compare with another)
– Applicable to any propositional feature models
• Full support of propositional constraints
• Different hierarchies [Van Den Broek et al., 2010]
– Syntactical strategies fail [Alves et al., 2006], [Segura et al., 2007]
37
see Chapter 5, [Acher et al., SLE’09] or [Acher et al., ECMFA’10]
38. Outline
• Towards Multiple Feature Models
– Software Product Line Engineering
– Feature Model
– Issues in Feature Modeling
– Multiple Feature Models: Example
• Applying Separation of Concerns
– Composition
– Decomposition
• Supporting language: FAMILIAR
• Applications
• Conclusion and Perspectives
38
39. A first try
fm0
R
A P
A1 A2 P1 P2 P3
P1 => P2
A3 A4 A5 A6 A3 => P1
P2 => A5
fmExtraction2
fmExtraction1
A
A
A3 => A5
A1
A1 A2
A2 A4 => A6
A3 A4
A4 A5
A5 A6
A6
Problem: You can select A3 without A5
We want a more generic, semantics-aware technique
39
40. Slicing Operator
slicing criterion: subset of features fm1
W
P T U
Optional Xor-Group
Mandatory
Or-Group R S V A
constraints
E implies D B C D
R implies E
D excludes F
S implies (F and not E) E F
constraints T
E implies D
D implies E
slice: a new feature model S E D
40
41. How to implement the slice operator?
fm1
W
φ1
P T U
Optional Xor-Group
Mandatory
Or-Group R S V A
constraints
E implies D B C D
R implies E
D excludes F
existential S implies (F and not E) E F
quantification
of features T
+
not included
φ in the slicing
s1 criterion S E D
constraints T
E implies D
D implies E
S E D 41
42. Corrective Capabilities of the
Slicing Operator
slicing criterion: subset of features fm1
W
P T U
Optional Xor-Group
Mandatory
Or-Group R S V A
constraints
E implies D B C D
R implies E
D excludes F
S implies (F and not E) E F
P
slice: a new feature model R S
42
43. Updating feature model views
FMgrid
GridDeployment
FMalgo
Library Required
GridComputingNode MI Algorithm
Matlab Method Interactive
OS Processor FileSizeLimit Authentification Model FMalgo_UPDATED
Atlas Linear Non Grid
MI Algorithm
Windows Linux Bits GPU PAM BAM
CFL EMS Affine
Kerberos Password SSLAuth Method Interactive
x32 x64 Rotation Scaling
Ubuntu Sc. Linux Sc. Linux excludes MatLab EMS implies Affine or Scaling
:grid
:alg Model
Medical Imaging
Registration Service
PAM
FMproto :proto :out
NetworkProtocol FMMIsupport
Medical Image
TransferProtocol NetworkSecurity Header
Encoding
ModalityAcquisition Format
HTTPS HTTP Crypto PGP SSL
MRI CT SPEC PET Name MetaData
Asymetric Symetric
Anonymized
DES TripleDES KDC T1 T2
DICOM Nifti Analyze FMMIsupport_UPDATED
HeaderEncoding implies HTTPS
MetaData implies DICOM or Analyze Medical Image
constraints Analyze excludes (CT and SPEC and T1)
FMgrid..Kerberos implies FMproto.KDC ModalityAcquisition Format
FMgrid..SSLAuth FMproto.SSL MRI CT PET Name MetaData
FMMIsupport.MRI implies FMalgo.PAM
Anonymized
FMMIsupport.CT or FMMIsupport.SPEC implies FMalgo.BAM T2
Nifti Analyze
FMMIsupport.Anonymized implies FMproto.HeaderEncoding MetaData implies Analyze
Analyze excludes CT
FMalgo.Interactive implies FMproto.HeaderEncoding
FMgrid.GPU excludes FMalgo.Interactive
FMalgo.Interactive implies FMgrid..Linux Aggregate + Slice
FMMIsupport.DICOM implies FMproto.Rotation and FMproto.PAM
43
44. Supporting Multiple Perspectives
FMgrid
GridDeployment
FMalgo
Library Required
GridComputingNode MI Algorithm
Matlab Method Interactive
OS Processor FileSizeLimit Authentification Model
constraints
Atlas Linear Non Grid
Windows Linux Bits GPU PAM BAM FMgrid..Kerberos implies FMproto.KDC
CFL EMS Affine
Kerberos Password SSLAuth FMgrid..SSLAuth FMproto.SSL
x32 x64 Rotation Scaling
Ubuntu Sc. Linux Sc. Linux excludes MatLab EMS implies Affine or Scaling FMMIsupport.MRI implies FMalgo.PAM
:grid
:alg
Medical Imaging FMMIsupport.CT or FMMIsupport.SPEC implies FMalgo.BAM
Registration Service
FMMIsupport.Anonymized implies FMproto.HeaderEncoding
FMproto :proto :out
NetworkProtocol FMMIsupport FMalgo.Interactive implies FMproto.HeaderEncoding
Medical Image
Header
FMgrid.GPU excludes FMalgo.Interactive
TransferProtocol NetworkSecurity
Encoding
Crypto
ModalityAcquisition Format FMalgo.Interactive implies FMgrid..Linux
HTTPS HTTP PGP SSL
Asymetric Symetric MRI CT SPEC PET Name MetaData FMMIsupport.DICOM implies FMproto.Rotation and FMproto.PAM
Anonymized
DES TripleDES KDC T1 T2
DICOM Nifti Analyze
HeaderEncoding implies HTTPS
MetaData implies DICOM or Analyze Security features
Analyze excludes (CT and SPEC and T1)
The same feature models and constraints
Aggregate + Slice
44
45. Contributions
– Design of a decomposition mechanism
• “slicing”
– Guarantee semantics properties by construction
– Applicable to any propositional feature models
• Including with “errors”
• Full support of propositional constraints
– New capabilities when combining composition and
decomposition operators
45
see Chapter 7 or [Acher et al., ASE’11]
46. Outline
• Towards Multiple Feature Models
– Software Product Line Engineering
– Feature Model
– Issues in Feature Modeling
– Multiple Feature Models: Example
• Applying Separation of Concerns
– Composition
– Decomposition
• Supporting language: FAMILIAR
• Applications
• Conclusion and Perspectives
46
47. The birth of FAMILIAR
• We have no practical means to…
– Use and combine the operators
– Perform sequences of operations (reasoning / editing)
• We want to replay and reuse analysis procedures
• A language is needed…
– Graphical language
– General purpose language (API/framework)
• FAMA [Benavides et al., 2008], SPLOT [Mendonca et al., 2009], FeatureIDE [Thuem,
Kästner et al., 2009]
– Domain-specific language
• FAMILIAR
FeAture Model scrIpt Language for manIpulation and Automatic Reasoning
see chapters 8 and 9, [Acher et al., SAC’11], [Acher et al., VaMoS’11] or [Acher et al., ASE’11]
47
48. And-Group Xor-Group
GraphicCard
Optional Or-Group
Mandatory
Outputs DirectX TV output
VIVO DVI HDMI VGA V10 V10.1 v11
// foo.fml
constraints
S-Video Composite
VGA excludes TV output
HDMI implies v10.1 or v11
fm1 = FM (“foo1.tvl”)
constraints
……..
fm2 = FM (“foo2.m”)
fm3 = merge intersection { fm1 fm2 }
c3 = counting fm3
True/False
renameFeature fm3.TV as “OutputTV”
fm5 = aggregate { fm3 FM (“foo4.xml”) } 8759
assert (isValid fm5) “OutputTV”, “TV”
constraints
……..
fm6 = slice fm5 including fm5.TV.* And-Group Xor-Group
export fm6
Optional Or-Group
Mandatory
constraints
……..
constraints
……..
domain-specific language
FAMILIAR
49. FAMILIAR… features
fm1 = FM(“foo.tvl”)
fm2 = FM (“foo.m”) serialize fm4 into SPLOT
fm3 = FM (“foo.xmi”)
fm4 = FM (A : B ….)
Interoperability serialize fm1 into featureide
configuration
counting configs cores deads select
isValid
compare Reasoning falseOptionals deselect
asFM
merge aggregate
diff insert
intersection
sunion (De)Composition extract
map
unmap
slicing
renameFeature setOptional
Editing
removeFeature setMandatory
accessors setAlternatives
copy setOr
modular mechanisms
fm1.* fm1.B
iterator/conditional
assertion
Language Facilities restricted set of types
49