Model-based Variability Management (tutorial at ECOOP/ECMFA/ECSA)

The customization of almost everything is observed in a wide range of domains. Many organizations should address the challenge of extending, changing, customizing or configuring numerous kinds of systems and artefacts (requirements, components, services, languages, architectural or design models, codes, user interfaces, etc.) for use in a particular context. As a result, modeling and managing variability of such systems and artefacts is a crucial activity in a growing number of software engineering contexts (e.g., software product lines, dynamic adaptive architectures). Numerous model-based techniques have been proposed and usually consist in i) a variability model (e.g., a feature model), ii) a model (e.g., a class diagram) expressed in a domain-specific modeling language (e.g., Unified Modelling language), and iii) a realization layer that maps and transforms variation points into model elements. Based on a selection of desired features in the variability model, a derivation engine can automatically synthesise customized models – each model corresponding to an individual product. In this tutorial, we present the foundations and tool-supported techniques of state-of-the-art variability modeling technologies. In the first part, we briefly exemplify the management of variability in some systems/artefacts (design models, languages, product configurators). We introduce the Common Variability Language (CVL), a representative approach and ongoing effort involving both academic and industry partners to promote standardization variability modeling technology. In the second part, we focus on feature models the most popular notation to formally represent and reason about commonality and variability of a software system. Feature modelling languages and tools, directly applicable to a wide range of model-based variability problems and application domains, are presented. The FAMILIAR language and environment is used to perform numerous management operations like the import, export, compose, decompose, edit, configure, compute diffs, refactor, reverse engineer, test, or reason about (multiple) feature models. We describe their theoretical foundations, efficient implementations, and how these operations can be combined to realize complex variability management tasks. In the third part, we show how to combine feature models and other modeling artefacts. We revisit the examples given in the first part of the tutorial, using the Kermeta workbench and familiarCVL, an implementation of CVL. Finally we present some of the ongoing challenges for variability modeling. At the end of the tutorial, participants (being practitioners or academics, beginners or advanced) will learn languages, tools and novel variability modeling techniques they can directly use in their industrial contexts or as part of their research.

Transcript

1. Mathieu  Acher,  Benoit  Combemale,  Olivier  Barais  
   Model-­‐Based    
   Variability  Management  
    
   

   View Slide

2. 2  
   Research  in  so6ware  
   engineering.  
   -­‐  8  faculty  members  
   -­‐  35  researchers  and  
   engineers  on  projects  
   

   View Slide

3. We’re  hiring!    
   engineers,  PhD  students,  post-­‐docs
    
   Variability  /  Product  lines    
   Model-­‐driven  Engineering  
   Language  Engineering  (e.g.,  DSLs)  
   Scala  
   3  
   3  
   European  Projects    
    
   Industrial  CollaboraCons  
    
   Academics  partners  
   

   View Slide

4. Acknowledgments  (la  famille)  
   Marianela  Ciolfi  Felice    
   Joao  Bosco  Ferreira  Filho  
   Guillaume  Bécan  
   Suresh  Pilay    
   Sana  Ben  Nasr  
   (MSc/PhD  students,    
   University  of  Rennes  1)  
    
   Prof.  Philippe  Collet  
   Prof.  Philippe  Lahire    
   (University  of  Nice  Sophia  AnWpolis)  
    
   Prof.  Robert  B.  France    
   (Colorado  State  University)  
    
   Prof.  Patrick  Heymans    
   (University  of  Namur)  
   

   View Slide

5. Audience  
   •  No  pre-­‐requisite  background!  
   •  Targeted  Audience  
   •  Academics  or  pracWWoners    
   •  Curious  guys:  e.g.,  PhD  students  or  modellers  unaware  of…    
   –  Variability  and  so6ware  product  lines  (SPLs)  
   –  Variability  modelling    
   –  ConfiguraWon  
   •  MDE  guys:  people  involved  or  interested  in  the  development  of  
   model  management  tools  
   –  e.g.,  model  composiWon/decomposiWon  
   •  SPL  guys:  advances  that  want  to  learn  new  techniques  
   5  
   

   View Slide

6. At  the  end  of  the  tutorial…  
   •  You  will  have  an  overview  of  what’s  going  on  in  the  field  of    
   variability  and  model-­‐based  so6ware  product  line  engineering  
   •  You  will  be  able  to  go  further  with  the  languages  and  modelling  
   techniques  
   •  so  to  reuse  them  in  pracWcal  or  academic  contexts    
   •  SupporWng  material:  
   hbps://github.com/FAMILIAR-­‐project/familiar-­‐documentaWon/blob/
   master/presentaWons/EC2013/README.md    
   •  slides  of  the  tutorial  
   •  related  arWcles,    
   •  FAMILIAR  scripts,  
   •  CVL  models,  
   •  and  packaged  tools  to  interacWvely  play  with  the  models  during  the  
   tutorial  
   6  
   

   View Slide

7. Differences  with  previous  tutorials  at  
   SPLC’12  /  MODELS’12  
   •  Larger  perspecWve/moWvaWon  
   •  Including  modelling/language/architectural  examples  
    
   •  Not  only  about  feature  models  
   •  not  only  about  FAMILIAR  
   •  but  new  techniques  for  reverse  engineering  (VaMoS’13)  and  composing  
   (MODELS’13)  feature  models  will  be  presented    
   •  Model-­‐based  product  line  engineering  
   •  Common  Variability  Language  (CVL)  
   FAMILIAR  is  now  a  project  
    not  only  a  language  for  managing  feature  models!  
   7  
   

   View Slide

8. [MOTIVATION/PROBLEM]  Why  modeling  and  managing  Variability  
   does  and  will  maber  (30’)  
   [SOLUTION  FOR  MANAGING  FEATURE  MODELS]  Managing  Variability  
   Models  with  FAMILIAR  (1h45’)  
    
    
   [SOLUTION  FOR  MODEL-­‐BASED  DERIVATION  OF  PRODUCT]  Model-­‐based  
   variability  engineering:  examples,  support  and  open  issues  
   (45’)  
   8  
   Plan  
   

   View Slide

9. [MOTIVATION/PROBLEM]  Why  modeling  and  managing  Variability  
   does  and  will  maber  (30’)  
   [SOLUTION  FOR  MANAGING  FEATURE  MODELS]  Managing  Variability  
   Models  with  FAMILIAR  (1h45’)  
    
    
   [SOLUTION  FOR  MODEL-­‐BASED  DERIVATION  OF  PRODUCT]  Model-­‐based  
   variability  engineering:  examples,  support  and  open  issues  
   (45’)  
   9  
   Plan  
   

   View Slide

10. 10  
    So6ware-­‐intensive  systems  
    come  in  many  variants    
    

    View Slide

11. View Slide

12. Linux  
    Kernel  
    

    View Slide

13. Database  
    Engine  
    

    View Slide

14. Printer  
    Firmware  
    

    View Slide

15. Features  in  MicrosoS  Office  
    15  
    

    View Slide

16. View Slide

17. View Slide

18. Variability    
    “the  ability  of  a  system  to  be  efficiently  extended,  
    changed,  customized  or  configured  for  use  in  a  
    parCcular  context”    
    Mikael  Svahnberg,  Jilles  van  Gurp,  and  Jan  Bosch  (2005)  
    

    View Slide

19. «  A  set  of  programs  is  considered  to  consWtute  
    a  family,  whenever  it  is  worthwhile  to  study  
    programs  from  the  set  by  first  studying  the  
    common  properCes  of  the  set  and  then  
    determining  the  special  properCes  of  the  
    individual  family  members  »  
     
     
     
     
     
    David  L.  Parnas  —  ‘‘On  the  design  and  development  of  program  
    families’’  in  TransacCons  on  SoSware  Engineering,  SE-­‐2(1):1–9,  1976    
    19  
    aka  Variability  
    

    View Slide

20. Variability    
    “the  ability  of  a  system  to  be  efficiently  
    extended,  changed,  customized  or  
    configured  for  use  in  a  parCcular  context”    
    Mikael  Svahnberg,  Jilles  van  Gurp,  and  Jan  Bosch  (2005)  
     
     
    20  
    

    View Slide

21. 21  
    21  
    Extensible  architectures  
    (eg  plugins-­‐based)  
    ConfiguraCon  
    files  
    System  
    Preferences  
    Configurators  
    Source  code  
    Build  
    systems  
    Comparison  of  *  
    Structural  or  behavorial    
    models  
    External  Variability  
    Internal  Variability  
    Variability  @  run.Cme  
    

    View Slide

22. 22  
    «  Feature  Model  ExtracWon  from  Large  CollecWons  of  Informal  Product  DescripWons  »    
    Jean-­‐Marc  Davril,  Edouard  Delfosse,  Negar  Hariri,  Mathieu  Acher,  Jane  Cleland-­‐Huang,  Patrick  
    Heymans  (ESEC/FSE’13)  
    

    View Slide

23. 23  
    «  The  Anatomy  of  a  Sales  Configurator:  An  Empirical  Study  of  111  Cases  »  Ebrahim  Khalil  Abbasi,  
    Arnaud  Hubaux,  Mathieu  Acher,  QuenWn  Boucher,  and  Patrick  Heymans  (CAiSE’13)  
    

    View Slide

24. 24  
    «  ExtracWon  and  EvoluWon  of  Architectural  Variability  Models  in  Plugin-­‐based  Systems  »      
    Mathieu  Acher,  Anthony  Cleve,  Philippe  Collet,  Philippe  Merle,  Laurence  Duchien,  Philippe  
    Lahire  ECSA/SoSyM’13  
    

    View Slide

25. If  you’re  able  to  master  variability…  
    •  Reduce  development  costs    
    •  Reduce  cerWficaWon  costs    
    •  Shorten  Wme-­‐to-­‐market    
    •  But,  are  you  able?    
    – developing,  verifying,  cerWfying  billions  of  variants  is  
    challenging!  
     
    25  
    

    View Slide

26. Variability = Complexity
    ChrisWan  Kästner  slide  
    

    View Slide

27. a  unique  variant  for  every  
    person  on  this  planet  
    33  features  
    opWonal,  independent  
    ChrisWan  Kästner  slide  
    

    View Slide

28. 320  features  
     
    more  variants  than  esWmated  
       atoms  in  the  universe  
    opWonal,  independent  
    

    View Slide

29. 2000  features  
    10000  
    features  
    ChrisWan  Kästner  slide  
    

    View Slide

30. 30  
     
     
    Avoid  solving  the  same  problem!  
     
     
     2,  3…n  Cmes    
    AutomaCon?  
    

    View Slide

31. 31  
    Unused  flexibility  
    

    View Slide

32. 32  
    Illegal  variant  
    

    View Slide

33.  
     
    Goal:  So6ware  mass  customizaWon    
    /  AdapWve  and  configurable  systems  
     
    Problem:  Variability  =  Complexity  
     
    Approach:  Model-­‐based  variability  management  
    33  
    Why  managing  Variability    
    does  (and  will)  maier  
    

    View Slide

34. 34  
    So6ware-­‐intensive  systems  
    come  in  many  variants    
    Model-­‐based    
    Variability  Management  
    

    View Slide

35.  
    Modeling  Variability  
     
    CommunicaCve  
     
    AnalyCc  
     
    GeneraCve  
      35  
    

    View Slide

36. View Slide

37. View Slide

38. 38  
    Factoring  out  commonaliCes  
     for  Reuse  [Krueger  et  al.,  1992]  [Jacobson  et  al.,  1997]  
     
     
     
     
     
     
    Managing  variabiliCes    
     for  So6ware  Mass  CustomizaCon  [Bass  et  al.,  1998]  [Krueger  et  al.,  2001],  [Pohl  et  al.,  2005]  
     
     
    

    View Slide

39. Mobile
    3G+ 3G GPS
    Maps
    Camera ü  
    ü  
    ü  
    Mobile
    3G+ 3G GPS
    Maps
    Camera
    Domain/Variability  Model  
    ConfiguraCon   SoSware  Generator  
    Domain  Artefacts    
     
    Domain    
    Engineering  
    ApplicaCon    
    Engineering  
    «  the  investments  required  to  develop  the  reusable  arBfacts  during  
    domain  engineering,  are  outweighed  by  the  benefits  of  deriving  the  
    individual  products  during  applica.on  engineering  »  
    Jan  Bosch  et  al.  (2004)      
    

    View Slide

40. 40  
    99%  domain  engineering,    
    1%  applicaCon  engineering?  
    –  specifies  what  you  want  (click,  click,  click)  a  customized  
    product  is  automaWcally  built  for  you  
    –  Iterate  the  process  for  n  products  
    Amount
    of
    effort
    Application
    Engineering
    More Sophisticated
    Technology
    Domain
    Engineering
    

    View Slide

41. Variability  AbstracCon  
    Model  (VAM)  
    ConfiguraCon  
    (resoluCon  model)  
    Domain  Artefacts  
    (e.g.,  models)  
    SoSware  Generator  
    (derivaCon  engine)  
    ü   ü  
    Variability  
    RealizaCon  
    Model  
    (VRM)  
    

    View Slide

42. View Slide

43. Configurations
    Derivation
    Process
    Models of
    the
    “system”
    Feature
    Model
    How to
    realize the
    variability
    

    View Slide

44. (another  research  area/applicaWon:  
    adapWve  systems  aka  dynamic  so6ware  product  lines  
    Models@run.Wme)  
    hip://www.kevoree.org  
    from  Cloud  stack  to  
    embedded  devices  
    

    View Slide

45. View Slide

46. Variability  Handling  in  AUTOSAR  
    Body  
    control  
    Low-­‐end  light-­‐
    control  
    AdapWve-­‐curve  
    light-­‐control  
    Feature  Modeling  
    (Variability  abstracWon)  
    Generic  Template  
    (Variability  RealizaWon)  
    LightType  
    …   System  
    constant  
    Low  End   High  End  
    Car  
    1..1
    Feature  
    v.  4.04  (upcoming)  
    v.  4.03  
    Low  End  ==  1  
    High  End  ==  1   VariaWon  
    point  
    Adapted  from  the  CVL  tutorial  at  SPLC’12  by  Oystein  Haugen,  Andrezj  Wasowski,  Krzysztof  Czarnecki    
    

    View Slide

47. Variability  Handling  in  AUTOSAR  (2)  
    Feature  Modeling  
    (Variability  abstracWon)  
    Generic  Template  
    (Variability  RealizaWon)  
    Low  End   High  End  
    Car  
    1..1
    Body  
    control  
    Low-­‐end  
    light-­‐control  
    

    View Slide

48. VariaCon  Point  Types  
    •  Variability  is  applied  to  different  parts  of  the  
    metamodel  
    – AggregaWon,  associaWon,  abribute  value,  property  
    set  
    •  ResulWng  variability  
    – OpWonal  component  
    – OpWonal  port  
    – OpWonal  connector  
    – Parameter  variability  
    Component  
    Port  
    Adapted  from  the  CVL  tutorial  at  SPLC’12  by  Oystein  Haugen,  Andrezj  Wasowski,  Krzysztof  Czarnecki    
    

    View Slide

49. 49  
    «  Mapping  Features  to  Models:  A  Template  Approach  Based  on  Superimposed  Variants»  
    Krzysztof  Czarnecki  and  Michal  Antkiewicz  GPCE’05  
    

    View Slide

50. 50  
    «  Mapping  Features  to  Models:  A  Template  Approach  Based  on  Superimposed  Variants»  
    Krzysztof  Czarnecki  and  Michal  Antkiewicz  GPCE’05  
    

    View Slide

51. 51  
    «  Mapping  Features  to  Models:  A  Template  Approach  Based  on  Superimposed  Variants»  
    Krzysztof  Czarnecki  and  Michal  Antkiewicz  GPCE’05  
    

    View Slide

52. 52  
    «  Mapping  Features  to  Models:  A  Template  Approach  Based  on  Superimposed  Variants»  
    Krzysztof  Czarnecki  and  Michal  Antkiewicz  GPCE’05  
    

    View Slide

53. Safe  composiWon?  No!  
    53  
    «Verifying  Feature-­‐Based  Model  Templates  Against  
    Well-­‐Formedness  OCL  Constraints  »  Krzysztof  Czarnecki  Krzysztof  Pietroszek  GPCE’06  
    

    View Slide

54. Ooops  
    54  
    «Verifying  Feature-­‐Based  Model  Templates  Against  
    Well-­‐Formedness  OCL  Constraints  »  Krzysztof  Czarnecki  Krzysztof  Pietroszek  GPCE’06  
    

    View Slide

55. Another  approach  
    55  
    «  Reconciling  AutomaWon  and  Flexibility  in  Product  DerivaWon  »  Gilles  Perrouin,  Jacques  Klein,  
    Nicolas  Guelfi,  Jean-­‐Marc  Jézéquel  SPLC’08  
    

    View Slide

56. 56  
    «  Reconciling  AutomaWon  and  Flexibility  in  Product  DerivaWon  »  Gilles  Perrouin,  Jacques  Klein,  
    Nicolas  Guelfi,  Jean-­‐Marc  Jézéquel  SPLC’08  
    Merging-­‐based  DerivaCon  of  Product  
    

    View Slide

57. View Slide

58. Variability  at  the  language  level  
     
    58
    Variability  in  
    Metamodeling  
    •  SemanWc  variaWon  point  
    •  DSML  Families  
    •  Knowledge  capitalizaWon  
    •  Language  Engineering  
     
    Variability  in  
    Modeling  
    Variability
    
    Variability
    
    

    View Slide

59. 
    
     
    
    
    
    
    
    
    
    
    
    
     Engineering  SemanCcs  in  Modeling  Languages  
    59
    Abstract
    Syntax
    (AS)
    Concrete
    Syntax
    (CS)
    Semantics
    Domain
    (SD)
    Mac
    Mas
    •  Variability  in  metamodeling  (DSML  families,  variaWon  point...):  
    –  Abstract  syntax:  staWc  introducWon  (AOM),  inheritance  (OOP)  
    –  Concrete  syntax:  view  point  (OBEO  Designer)  
    –  SemanWcs:  sWll  a  problem!  how  to  define  and  manage  semanBc  
    variability  (in  the  DSML  and  the  associated  tools)?  
    

    View Slide

60. DSL4  
    DSL3  
    DSL2  
    DSL1  
    Language  Family  
    (expresiveness,  semanWc  variaWon  point,    
    implementaWon  variaWon  point,  viewpoints,  tooling,  etc.)  
    RM  
    dsl1  
    RM  
    dsl2  
    RM  
    dsl3  
    RM  
    dsl4  
    Challenge1:  Modular  
    Language  Design  
    Challenge3:  
    Language  
    ComposiWon  
    Challenge2:  
    Variability  Modeling  
    «  Variability  Management  in  Modeling  Languages  »  Suresh  Pilay  PhD  thesis  (ongoing)  
    

    View Slide

61. DSL  
    Variability  
    model  
    CVL  
    Base    
    model  
    Generic  &    
    Standardized  
    resoluCon  
    models  
    Focused  on    
    a  domain  
    Execute  CVL  
     
     
    Resolved    
    models  
    DescripWon  of  
    possible  
    variaWons  in  
    the  system  
    Domain  
    model  of  a  
    parWcular  
    family  of  
    system
     
    SelecWon  of  a  set  
    of  opWons  in  the  
    variaWon  model
     
    Family  of  systems  fully  
    described  in  the  
    domain  specific  
    language.  
    All  regular  DSL  tools  
    can  be  applied  to  these  
    models  
    61  
    RealizaCon  
    model  
    Language
    Units
    Language
    Features
    how to realize
    the features
    Configuration
    of languages
    Derivation
    Process
    Languages
    «  Variability  Management  Modeling  Languages  »  Suresh  Pilay  PhD  thesis  (ongoing)  
    

    View Slide

62. View Slide

63. 63  
    «  ExtracWon  and  EvoluWon  of  Architectural  Variability  Models  in  Plugin-­‐based  Systems  »      
    Mathieu  Acher,  Anthony  Cleve,  Philippe  Collet,  Philippe  Merle,  Laurence  Duchien,  Philippe  
    Lahire  ECSA/SoSyM’13  
    

    View Slide

64. 64  
    «  ExtracWon  and  EvoluWon  of  Architectural  Variability  Models  in  Plugin-­‐based  Systems  »      
    Mathieu  Acher,  Anthony  Cleve,  Philippe  Collet,  Philippe  Merle,  Laurence  Duchien,  Philippe  
    Lahire  ECSA/SoSyM’13  
    FraSCAti
    SCAParser
    Java Compiler
    JDK6 JDT
    Optional
    Mandatory
    Alternative-
    Group
    Or-Group
    Assembly Factory
    rest
    http
    Binding
    MMFrascati
    Component Factory
    Metamodel
    MMTuscany
    constraints
    rest requires MMFrascati
    http requires MMTuscany
    FM1
    Variability  Model  
    

    View Slide

65. 65  
    Variability  Model  
    FraSCAti
    SCAParser
    Java Compiler
    JDK6 JDT
    Optional
    Mandatory
    Alternative-
    Group
    Or-Group
    Assembly Factory
    rest
    http
    Binding
    MMFrascati
    Component Factory
    Metamodel
    MMTuscany
    constraints
    rest requires MMFrascati
    http requires MMTuscany
    FM1
    FraSCAC  Architecture  
    Set  of    Safe  
    Variants  
    authorized  by  
    FraSCAC  
    Scope  is  
    too  large  
    

    View Slide

66. Illegal    Variant    
    66  
    

    View Slide

67. 67  
    FraSCAC  Architecture  
    FraSCAti
    SCAParser
    Java Compiler
    JDK6 JDT
    Optional
    Mandatory
    Alternative-
    Group
    Or-Group
    Assembly Factory
    rest
    http
    Binding
    MMFrascati
    Component Factory
    Metamodel
    MMTuscany
    constraints
    rest requires MMFrascati
    http requires MMTuscany
    FM1
    Feature  Model  
    FraSCAti
    SCAParser
    Java Compiler
    JDK6 JDT
    Optional
    Mandatory
    Alternative-
    Group
    Or-Group
    Assembly Factory
    rest
    http
    Binding
    MMFrascati
    Component Factory
    Metamodel
    MMTuscany
    constraints
    rest requires MMFrascati
    http requires MMTuscany
    FM1
    ConfiguraCon   Derived  FraSCAC  Architecture  
    

    View Slide

68. [MOTIVATION/PROBLEM]  Why  modeling  and  managing  Variability  
    does  and  will  maber  (30’)  
    [SOLUTION  FOR  MANAGING  FEATURE  MODELS]  Managing  Variability  
    Models  with  FAMILIAR  (1h45’)  
     
     
    [SOLUTION  FOR  MODEL-­‐BASED  DERIVATION  OF  PRODUCT]  Model-­‐based  
    variability  engineering:  examples,  support  and  open  issues  
    (45’)  
    68  
    Plan  
    

    View Slide

69. Variability  Model  
    ConfiguraCon  
    Domain  Artefacts  (e.g.,  source  code)  
    SoSware  Generator  
    Modeling  
    variability    
    is  crucial  
    ü   ü  
    

    View Slide

70. 70  
    Unused  flexibility  
    

    View Slide

71. 71  
    Illegal  variant  
    

    View Slide

72. 72  
    72  
    Extensible  architectures  
    (plugins-­‐based)  
    ConfiguraCon  
    files  
    System  
    Preferences  
    Configurators  
    Source  code  
    Build  systems  
    Comparison  of  Product  
    

    View Slide

73.  
    Variability  AbstracCon  Model  
    (VAM)  
     
    CommunicaCve  
     
    AnalyCc  
     
    GeneraCve  
      73  
    not, and, or, implies
    

    View Slide

74. Variability  Model  
    Feature  Model:  de  facto  standard  
    •  Research    
    –  2500+  citaWons  of  [Kang  et  al.,  1990]  on  Google  Scholar    
    –  Central  to  many  generaWve  approaches  
    •  at  requirements  or  code  level  
    –  Tools  &  Languages  (GUIDSL/FeatureIDE,  SPLOT,  FaMa,  
    etc.)  
    •  Industry    
    –  Tools  (Gears,  pure::variants),    
    •  Common  Variability  Language  (CVL)  
    74  
    

    View Slide

75. View Slide

76. Feature  Models  
    76  
    

    View Slide

77. Feature  Models  (Background)  
    77  
    Hierarchy:  rooted  tree    
    Variability:    
    •  mandatory,    
    •  opWonal,    
    •  Groups:  exclusive  or  inclusive  features  
    •  Cross-­‐tree  constraints  
    Optional
    Mandatory
    Xor-Group
    Or-Group
    

    View Slide

78. 78  
    Hierarchy  +  Variability    
    =    
    set  of  valid  configuraCons  
    {CarEquipment,  Comfort,  DrivingAndSafety,  Healthing,  AirCondiWoning,  FrontFogLights}  
    configuraCon  =  set  of  features  selected  
    Optional
    Mandatory
    Xor-Group
    Or-Group
    

    View Slide

79. 79  
    Hierarchy  +  Variability    
    =    
    set  of  valid  configuraCons  
    {CarEquipment,  Comfort,  DrivingAndSafety,  Healthing,  AirCondiWoning}  
    configuraCon  =  set  of  features  selected  
    Optional
    Mandatory
    Xor-Group
    Or-Group
    

    View Slide

80. 80  
    Hierarchy  +  Variability    
    =    
    set  of  valid  configuraCons  
    Optional
    Mandatory
    Xor-Group
    Or-Group
    {CarEquipment,  Comfort,  DrivingAndSafety,  Healthing,  AirCondiWoning,  
    AutomaWcHeadLights}  
    configuraCon  =  set  of  features  selected  
    ü  
    ü  
    ü  
    ü  
    ü  
    ü  
    

    View Slide

81. 81  
    Hierarchy  +  Variability    
    =    
    set  of  valid  configuraCons  
    Optional
    Mandatory
    Xor-Group
    Or-Group
    {AirCondiWoning,  FrontFogLights}  
    {AutomaWcHeadLights,  AirCondiWoning,  FrontFogLights}  
    {AutomaWcHeadLights,  FrontFogLights,  AirCondiWoningFrontAndRear}  
    {AirCondiWoningFrontAndRear}  
    {AirCondiWoning}  
    {AirCondiWoningFrontAndRear,  FrontFogLights}  
    {CarEquipment,  Comfort,  
    DrivingAndSafety,  
    Healthing}  
    X
    

    View Slide

82. Feature  Models  
    82  
    

    View Slide

83. View Slide

84.  (FeAture  Model  scrIpt  Language  for  manIpulaWon  and  AutomaWc  Reasoning)    
    not, and, or, implies
    φ
    TVL
    DIMACS
    hip://familiar-­‐project.github.com/  
    Mathieu  Acher,  Philippe  Collet,  Philippe  Lahire,  Robert  B.  France  «  A  Domain-­‐Specific  Language  for  Large-­‐
    Scale  Management  of  Feature  Models  »  Science  of  Computer  Programming  (SCP),  2013  
    

    View Slide

85. 85  
    Optional
    Mandatory
    Xor-Group
    Or-Group
    

    View Slide

86. 86  
    Optional
    Mandatory
    Xor-Group
    Or-Group
    

    View Slide

87. 87  
    Optional
    Mandatory
    Xor-Group
    Or-Group
    {AirCondiWoning,  FrontFogLights}  
    {AutomaWcHeadLights,  AirCondiWoning,  
    FrontFogLights}  
    {AutomaWcHeadLights,  FrontFogLights,  
    AirCondiWoningFrontAndRear}  
    {AirCondiWoningFrontAndRear}  
    {AirCondiWoning}  
    {AirCondiWoningFrontAndRear,  FrontFogLights}  
    {CarEquipment,  Comfort,  
    DrivingAndSafety,  
    Healthing}  
    X
    

    View Slide

88. View Slide

89. View Slide

90.  (FeAture  Model  scrIpt  Language  for  manIpulaWon  and  AutomaWc  Reasoning)    
    imporCng,  exporCng,  composing,  decomposing,  ediCng,  configuring,  
    reverse  engineering,  compuCng  "diffs",  refactoring,  tesCng,    
    and  reasoning  about  (mulCple)  variability  models  
    not, and, or, implies
    φ
    TVL
    DIMACS
    hip://familiar-­‐project.github.com/  
    Mathieu  Acher,  Philippe  Collet,  Philippe  Lahire,  Robert  B.  France  «  A  Domain-­‐Specific  Language  for  Large-­‐
    Scale  Management  of  Feature  Models  »  Science  of  Computer  Programming  (SCP),  2013  
    

    View Slide

91. #1  Automated  Analysis  
    91  
    

    View Slide

92. #2  MulCple  Feature  Models  
    92  
    

    View Slide

93. 93  
    93  
    MulC-­‐*  variability  
     
     
     
     
    *systems,  perspecCves,  or  stakeholders  
    

    View Slide

94. •  #1  Automated  analysis    
    –  Aka  support  to  beber  understand  and  play  with  your  feature  
    model  (TVL  model)  
    •  #2  Managing  mulCple  feature  models  
    –  Composing  /  Decomposing  /  Diff  and  Reasoning  about  their  
    relaWonships  
    –  Combining  these  operators  
    94  
    Two  Key  Requirements  
    

    View Slide

95. language  and  environment  
     
     
     
     
     
     
     
    And-Group
    Optional
    Mandatory
    Xor-Group
    Or-Group
    constraints
    ……..
    DirectX
    V10 V10.1 v11
    Outputs
    VIVO DVI HDMI
    S-Video Composite
    VGA
    GraphicCard And-Group
    Optional
    Mandatory
    Xor-Group
    Or-Group
    TV output
    constraints
    VGA excludes TV output
    HDMI implies v10.1 or v11
    constraints
    ……..
    constraints
    ……..
    constraints
    ……..
    //  foo.fml  
    fm1  =  FM  (“foo1.tvl”)  
    fm2  =  FM  (“foo2.m”)  
    fm3  =  merge  intersecCon  {  fm1  fm2  }  
    c3  =  counCng  fm3  
    renameFeature  fm3.TV  as  “OutputTV”  
    fm5  =  aggregate  {  fm3  FM  (“foo4.xml”)  }  
    assert  (isValid  fm5)      
    fm6  =  slice  fm5  including  fm5.TV.*    
    export  fm6  
     
    True/False  
    8759  
    “OutputTV”,  “TV”    
    Interoperability   Language  faciliCes   Environment  
    

    View Slide

96. 96  
    Interoperability  
    fm1  =  FM(“foo.tvl”)  
    fm2  =  FM  (“foo.m”)  
     
    serialize  fm4  into  SPLOT  
    serialize  fm1  into  featureide  
    fm3  =  FM  (“foo.xmi”)  
    fm4  =  FM  (A  :  B  ….)  
     
       De/ComposiCon  
    merge  
                         diff  
                         intersecWon  
                         sunion  
       
    aggregate  
     map  
     unmap  
    extract                                                      slicing  
    EdiCng  
    renameFeature  
     removeFeature  
    accessors    
     copy  
               
     
    Reasoning    
    counWng   configs  
    isValid  
    deads  
    cores  
    falseOpWonals  
    cleanup  
    configuraWon    
     select  
     deselect  
     asFM  
    compare  
    setOpWonal    
                         setMandatory  
    setAlternaWves  
       setOr  
     
     Language  FaciliCes  
    fm1.*   fm1.B  
    modular  mechanisms  
     
     
    restricted  set  of  types  
    iterator/condiWonal  
    asserWon  
    insert  
    features  
    

    View Slide

97. Hello  World  
    97  
    helloworld.fml  
    Optional
    Mandatory
    Xor-Group
    Or-Group
    

    View Slide

98. Typed  language    
    •  Domain-­‐specific  types  
    –  Feature  Model,    
    –  ConfiguraWon,    
    –  Feature,    
    –  Constraint    
    •  Other  types  include    
    –  Set  
    –  String    
    –  Boolean,    
    –  Enum,    
    –  Integer  and  Real.    
    •  A  set  of  operaWons,  called  operators,  are  defined  for  a  given  type.    
    98  
    basics2.fml  
    

    View Slide

99. Typed  language    
    99  
    basics2.fml  
    

    View Slide

100. Typed  language    
     100  
     basics2.fml  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

101. ImporCng/ExporCng  feature  models  
     101  
     FAMILIAR
     S2T2
     TVL
     feature-model-synthesis
     (visual configurator)
     (language)
     (language)
     FaMa
     Internal  notaWon  or  by  “filename  extensions”    
     basics3.fml  
     

     View Slide

102. Feature  Accessors  (1)  
     102  
     6Accessors.fml  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

103. Other  constructs  
     103  
     6Accessors2.fml  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

104. ConfiguraCon  
     104  
     conf.fml   Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

105. 105  
     φ FM
     A  ^  
     A  ó  B  ^    
     C  =>  A  ^  
     D  =>  A    
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

106. OperaCons  for  Feature  Models  (1)  
     106  
     φ
     operatorsFM.fml  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

107. OperaCons  for  Feature  Models  (2)  
     107  
     φ
     operatorsFM2.fml  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

108. OperaCons  for  Feature  Models  (3)  
     108  
     operatorsFM3.fml  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

109.  
      
      
      
      
        
      
      
        
      
      
      
      
        
      
      
      
      
      
      
      
      
        
      
      
      
      
      
      
      
      
        
      
      
      
     SoC  support  =  ComposiCon/DecomposiCon  
     for  managing  
     large,  complex  and  mulCple  
     feature  models  
     FORM  1998,  Tun  et  al.  2009  (SPLC),  Hartmann  2008  (SPLC),  Lee  et  al.  2010,  Czarnecki  2005,  Reiser  et  al.  2007  (RE  journal),  Hartmann  
     et  al.  2009  (SPLC),  Thuem  et  al.  2009  (ICSE),  Classen  et  al.  2009  (SPLC),  Mendonca  et  al.  2010  (SCP),  Dunghana  et  al.  2010,  Hubaux  et  
     al.  2011  (SoSyM),  Zaid  et  al.  2010  (ER),  She  et  al.,  2011  (ICSE),  etc.  
     

     View Slide

110. Composing  Feature  Models  (1)  
     110  
     aggregateBasics.fml  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

111. Composing  Feature  Models  (2)  
     111  
     aggregate1.fml  
     Previous  
     version  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

112. Composing  Feature  Models  (3)  
     112  
     mergeMI.fml  
     Mathieu  Acher,  Philippe  Collet,  Philippe  Lahire,  Robert  B.  France  «  Comparing  Approaches  for  
     ImplemenWng  Feature  Model  ComposiWon  »  ECMFA’10  
     

     View Slide

113. see  also  Thuem,  Kastner  and  Batory,  ICSE’09  
     Comparing  Feature  Models  
     113  
     compare.fml  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

114. View Slide

115. Merge  IntersecCon:  Available  Suppliers  
     115  
     ∩  
     ∩  
     A  customer  
     has  some  
     requirements  
     Suppliers?  
     Products?  
     

     View Slide

116. In  FAMILIAR  
     116  
     suppliersExample0.fml  
     

     View Slide

117. Merge  Union:  Availability  Checking  
     117  
     Can  suppliers  provide  all  products?  
     Yes!  
     “compare”  
        
      
     ∩  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

118. In  FAMILIAR  
     118  
     suppliersExample.fml  
     

     View Slide

119. Merging  operaCon:    implementaCon  issues  
     119  
     How  to  synthesise  a  feature  model  that  represents  
     the  union  of  input  sets  of  configuraCons?  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     T2
     MRI
     Medical Image
     Header
     Anonymized
     T1
     DICOM
     Header excludes DICOM
     Header implies Anonymized
     Anonymized v Header v ~DICOM v ~T1 v ~T2
     Anonymized v Header v DICOM v ~T1 v ~T2
     

     View Slide

120. 120  
     Merging  operaCon:  semanCc  issues  (2)  
     φ
     Union  
     IntersecWon    
     Diff  
      
     How  to  synthesise  a  feature  model  that  represents  
     the  union  of  input  sets  of  configuraCons?  
     

     View Slide

121. Merging  operaCon:  algorithm  
     121  
     φ
     1
     φ
     2
     φ
     3
     φ
     123
     merged  proposiWonal  formula  
     T2
     MRI
     Medical Image
     Header
     Anonymized
     T1
     DICOM
     merged  hierarchy  
     +  
     Set  mandatory  features  
     Detect  Xor  and  Or-­‐groups  
     Compute  “implies/excludes”  
     constraints  
     How  to  synthesise  a  feature  
     model  that  represents  the  
     union  of  input  sets  of  
     configuraCons?  
     see  also  [Czarnecki  SPLC’07  or  SPLC’12]  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

122. Merging  operaCon:  back  to  hierarchy  
     122  
     mergeNonPC.fml  
     >  configs  fm4  
     res12:  (SET)  {{C;A};{A;B};{A};{A;B;C}}  
     ?  
     Mathieu  Acher,  Benoit  Combemale,  Philippe  Collet,  Olivier  Barais,  Philippe  Lahire,  Robert  B.  
     France  «  Composing  your  ComposiWons  of  Variability  Models  »  MODELS’13  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

123. see  also  [Acher  et  al.,  ECMFA’10  /  MODELS’13]  
     – Well-­‐defined  semanWcs  
     – Guarantee  semanWcs  properWes  by  construcWon  
     – 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  proposiWonal  feature  models    
     •  Full  support  of  proposiWonal  constraints    
     •  Different  hierarchies  [Van  Den  Broek  et  al.,  SPLC’2010/2012]  
     – SyntacWcal  strategies  fail  [Alves  et  al.,  2006],  [Segura  et  al.,  2007]  
     123  
     Related  Works  
     

     View Slide

124. View Slide

125. 125  
     Problem:  mulCple  „car  models“    
     

     View Slide

126. 126  
     Problem:  mulCple  „car  models“    
     

     View Slide

127. 127  
     Problem:  mulCple  „car  models“    
     

     View Slide

128. 128  
     Problem:  mulCple  „car  models“    
      
     #2  –  boiom-­‐up:  elaborate  a  feature  model  for  each  model  line  and  merge  them  
     Two  modeling  approaches  
     #1  –  top-­‐down:  specify  constraints  (e.g.,  excludes)  of  all  model  lines  upfront  
      
     

     View Slide

129. 129  
     #1  top-­‐down  
     

     View Slide

130. 130  
     #1  boiom-­‐up  
     FM_1  
     FM_2  
     FM_3  
     FM_r  
     merge  
     

     View Slide

131. 131  
     #1  boiom-­‐up  (FAMILIAR)  
     FM_1  
     FM_2  
     FM_3  
     FM_r  
     merge  
     audiMerge.fml  
     

     View Slide

132. View Slide

133. 133  
     Building  “views”  of  a  feature  model  
     

     View Slide

134. •  Problem:  given  a  feature  model,  how  to  
     decompose  it  into  smaller  feature  models?  
     •  SemanWcs?  
     – What’s  the  hierarchy  
     – What’s  the  set  of  configuraWons?  
     134  
     Building  “views”  of  a  feature  model  
     

     View Slide

135. A  first  try  
     A3 => P1
     P2 => A5
     R
     A2
     A5 A6
     A1
     A3 A4
     A
     fm0
     P3
     P2
     P1
     P
     P1 => P2
     A2
     A5 A6
     A1
     A3 A4
     A
     fmExtraction1
     A2
     A5 A6
     A1
     A3 A4
     A
     fmExtraction2
     A3 => A5
     A4 => A6
     Problem:  You  can  select  A3  without  A5  
     Hierarchy  and  ConfiguraCon  maier!   135  
     

     View Slide

136. Slicing  Operator  
     W
     constraints
     E implies D
     R implies E
     D excludes F
     S implies (F and not E)
     P
     R S
     fm1
     A
     V
     T U
     B C D
     E F
     Optional
     Mandatory
     Xor-Group
     Or-Group
     T
     S E D
     constraints
     E implies D
     D implies E
     slicing  criterion  :  an  arbitrary  set  of  features,  relevant  for  a  feature  model  user  
     slice  :  a  new  feature  model,  represenWng  a  projected  set  of  configuraWons    
     136  
     

     View Slide

137. Slicing  operator:  going  into  details  
     projected  set  of  configuraCons  
     137  
     fm1  =  {    
     {A,B,C,D,E,P,R,T,U,W},    
     {A,B,C,F,P,S,T,U,W},    
     {A,B,C,D,E,P,R,T,W},    
     {A,B,C,F,P,S,T,V,W},    
     {A,B,C,F,P,S,T,U,V,W},    
     {A,B,C,F,P,S,T,W},    
     {A,B,C,D,E,P,R,T,V,W},    
     }  
     fm1  =  {    
     {A,B,C,D,E,P,R,T,U,W},    
     {A,B,C,F,P,S,T,U,W},    
     {A,B,C,D,E,P,R,T,W},    
     {A,B,C,F,P,S,T,V,W},    
     {A,B,C,F,P,S,T,U,V,W},    
     {A,B,C,F,P,S,T,W},    
     {A,B,C,D,E,P,R,T,V,W},    
     }  
     fm1p  =  {    
     {D,E,T},    
     {S,T},    
     {D,E,T},    
     {S,T},    
     {S,T},    
     {S,T},    
     {D,E,T}  
     }  
     fm1p  =  {    
     {D,E,T},    
     {S,T},    
     }  
     W
     constraints
     E implies D
     R implies E
     D excludes F
     S implies (F andnot E)
     P
     R S
     fm1
     A
     V
     T U
     B C D
     E F
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

138. +  
     T
     S E D
     constraints
     E implies D
     D implies E
     φ
     s1
     existenBal  
     quanBficaBon  
     of  features  
     not  included  
     in  the  slicing  
     criterion  
     138  
     fm1p  =  {    
     {D,E,T},    
     {S,T}  
     }  
     Slicing  operator:  going  into  details  
     synthesizing  the  corresponding  feature  model  
     S   E   D  
     T  
     W
     constraints
     E implies D
     R implies E
     D excludes F
     S implies (F andnot E)
     P
     R S
     fm1
     A
     V
     T U
     B C D
     E F
     φ
     1
     Mathieu  Acher,  Philippe  Collet,  Philippe  Lahire,  Robert  B.  France  «  SeparaWon  of  Concerns  in  
     Feature  Modeling:  Support  and  ApplicaWons  »  AOSD’12  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

139. T
     S E D
     constraints
     E implies D
     D implies E
     139  
     Slicing  operator  with  FAMILIAR  (1)  
     W
     constraints
     E implies D
     R implies E
     D excludes F
     S implies (F andnot E)
     P
     R S
     fm1
     A
     V
     T U
     B C D
     E F
     slicingOp2.fml  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

140. 140  
     Slicing  with  FAMILIAR  (2)  
     slicingOp.fml  
     

     View Slide

141. From  marke.ng,  
     customers,  product  
     management    
     From  exis.ng  so@ware  
     assets    (technical  variability)  
     Metzger,  Heymans  et  al.  “DisambiguaBng  the  DocumentaBon  of  Variability  in  Sofware  Product  
     Lines:  A  SeparaBon  of  Concerns,  FormalizaBon  and  Automated  Analysis“  (RE’07)  
     

     View Slide

142. V1 ⬄ f1
     V2 ⬄ f2
     V3 ⬄ f3
     From  marke.ng,  
     customers,  product  
     management    
     From  exis.ng  
     so@ware  assets    
     realizability  
     usefulness  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

143. Realizability  checking  
     aggregate  
     {{V1,V3,V2,VP1},  
     {V1,VP1},  
     {V3,VP1},    
     {VP1}}    
     merge  diff  
     (“unrealizable  products”
      
     φ
     1
     slice  (“realizable  part”)  
     2
     3 compare  
     4  
     Mathieu  Acher,  Philippe  Collet,  Philippe  Lahire,  Robert  B.  France  «  SeparaWon  of  Concerns  in  
     Feature  Modeling:  Support  and  ApplicaWons  »  AOSD’12    
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

144. With  FAMILIAR  
     144  
     realizibility.fml  
     

     View Slide

145. View Slide

146. 146  
     RevisiCng  Merge:    
     Aggregate  +  Slice  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

147. 147  
     RevisiCng  Aggregate,    
     Merge  and  Slice:    
      
     mergeWithAggregateMI.fml  
     Mathieu  Acher,  Benoit  Combemale,  Philippe  Collet,  Olivier  Barais,  Philippe  Lahire,  Robert  B.  
     France  «  Composing  your  ComposiWons  of  Variability  Models  »  MODELS’13  
     Optional
     Mandatory
     Xor-Group
     Or-Group
     

     View Slide

148. 148  
     Mathieu  Acher,  Benoit  Combemale,  Philippe  Collet,  Olivier  Barais,  Philippe  Lahire,  Robert  B.  
     France  «  Composing  your  ComposiWons  of  Variability  Models  »  MODELS’13  
     

     View Slide

149. 149  
     φ FM
      
      
      
      
      
      
     Feature  Model  Synthesis  Problem  
     [Czarnecki  et  al.,  SPLC’07]  
     [She  et  al.,  ICSE’11]  
     [Andersen  et  al.,  SPLC’12]  
     A  ^  
     A  ó  B  ^    
     C  =>  A  ^  
     D  =>  A    
     

     View Slide

150. φ
      
      
      
      
      
      
      
     « How to synthesise an
     accurate (w.r.t. the set of constraints/configurations)
     meaningful (maintainable by a user), and
     unique
     feature model? »
     hip://familiar-­‐project.github.com/  
     

     View Slide

151. φ
     (SAT solvers or
     Binary Decision Diagrams)
     The  knowledge  can  be:  
        
     inconsistent  (e.g.,  root  feature  specified  is  not  possible)  
     consistent  and  incomplete  (i.e.,  synthesis  algorithm  needs  
     addiWonal  informaWon)  
     consistent,  «  parCal  »  (e.g.,  not  all  the  hierarchy  is  specified)  and  
     actually  complete    
     Mathieu  Acher,  Patrick  Heymans,  Anthony  Cleve,  Jean-­‐Luc  Hainaut,  Benoit  Baudry  «  Support  for  
     Reverse  Engineering  and  Maintaining  Feature  Models  »  VaMoS’13  
     

     View Slide

152. #1  Reverse  Engineering  Scenarios  
     •  [Haslinger  et  al.,  WCRE’11],  [Acher  et  al.,  VaMoS’12]  
     φ
     V
     D
     Ad O
     T M K
     Ae C
     P R S
     C requires T
     Ae requires T
     S equals M
     V
     D
     Ad O
     T K
     Ae S
     P R M
     C requires T
     S equals M
     C
     0..1
     

     View Slide

153. #2  Refactoring  
     •  [Alves  et  al.,  GPCE’06],  [Thuem  et  al.,  ICSE’09]  
     φ
     V
     D
     Ad O
     T M K
     Ae C
     P R S
     C requires T
     Ae requires T
     S equals M
     

     View Slide

154. #3  Re-­‐Engineering  Feature  Models  of          
     repository  
     •  For  each  FM  we  execute  the  following  FAMILIAR  script…  
      
     •  …  And  we  «compare»  syntacWcally  fm1  and  fm2  
     •  semanWcal  comparison  is  not  needed:  we  know  that  they  are  refactoring  by  
     construcWon  (good  test  case  though  ;-­‐))  
     •  Results:  
     –  147  synthesised  FMs  (69  %)  were  exactly  the  same  as  input  FMs  ;    
     –  40  synthesised  FMs  (19%)  were  correcWons  of  input  FMs  ;    
     –  24  synthesised  FMs  (12%)  were  different  (knowledge  needed)  
     •  another  set  of  cross-­‐tree  constraints  was  synthesised.    
     •  feature  group  conflicts  in  six  cases  
     SpecificaCon  of  the  hierarchy  is  the  main  issue  
     φ
     

     View Slide

155. φ
      
      
      
      
      
      
     FAMILIAR  
     « Give me a formula
     and some knowledge,
     I will synthesise
     an accurate,
     meaningful,
     unique
     feature model »
     #1  Breathing  knowledge  into  feature  model  synthesis  
      formal  specificaWon  (consistency  and  completeness)  
      concrete  syntax  and  tooling  suport  
     #2  PracCcal  applicaCons  
      reverse  engineering,  refactoring/re-­‐engineering  of  feature  models  
        
     hip://familiar-­‐project.github.com/  
     Automated  support  is  highly  
     needed  (ongoing  work)  
     

     View Slide

156. [MOTIVATION/PROBLEM]  Why  modeling  and  managing  Variability  
     does  and  will  maber  (30’)  
     [SOLUTION  FOR  MANAGING  FEATURE  MODELS]  Managing  Variability  
     Models  with  FAMILIAR  (1h45’)  
      
      
     [SOLUTION  FOR  MODEL-­‐BASED  DERIVATION  OF  PRODUCT]  Model-­‐based  
     variability  engineering:  examples,  support  and  open  issues  
     (45’)  
     156  
     Plan  
     

     View Slide

157. Variability  AbstracCon  
     Model  (VAM)  
     ConfiguraCon  
     (resoluCon  model)  
     Domain  Artefacts  
     (e.g.,  models)  
     SoSware  Generator  
     (derivaCon  engine)  
     ü   ü  
     Variability  
     RealizaCon  
     Model  
     (VRM)  
     

     View Slide

158. Configurations
     Derivation
     Process
     Models of
     the
     “system”
     Feature
     Model
     How to
     realize the
     variability
     

     View Slide

159. Printer
     ´Blockª
     mainSupply:MainPower
     1
     Attributes
     Operations
     powerCtrl
     emgSupply:EmgPower
     1
     Attributes
     threshold:int
     Operations
     powerCtrl
     inputSection
     1
     highSpeedConnector
     1
     Attributes
     Operations
     MainPowerCtrl EmgPowerCtrl
     MainPower
     ´Blockª
     Values
     Operations
     powerCtrl
     EmgPower
     ´Blockª
     Values
     threshold:int
     powerCtrl
     VariaCon  Points  over  base  model  
     :ObjectExistence   :SlotValueAssignment  
     CVL variation points
     SYSML (base model) elements
     :ObjectExistence   :ObjectExistence  
     §  Variability  in  this  example:  
       Part  EmergencySupply  is  
     opWonal  
       Part  HighSpeedConnector  is  
     opWonal  
       Port  EmgPowerCtrl  on  block  
     Printer  is  opWonal  
       Value  of  abribute  threshold  in  
     block  EmergencyPower  is  
     variable  
     Adapted  from  the  CVL  tutorial  at  SPLC’12  by  Oystein  Haugen,  Andrezj  Wasowski,  Krzysztof  
     Czarnecki    
     

     View Slide

160. Printer
     ´Blockª
     mainSupply:MainPower
     1
     Attributes
     Operations
     powerCtrl
     emgSupply:EmgPower
     1
     Attributes
     threshold:int
     Operations
     powerCtrl
     inputSection
     1
     highSpeedConnector
     1
     Attributes
     Operations
     MainPowerCtrl EmgPowerCtrl
     MainPower
     ´Blockª
     Values
     Operations
     powerCtrl
     EmgPower
     ´Blockª
     Values
     threshold:int
     powerCtrl
     (Aiributed)  
     Feature  Model    
     Printer
      
     EmergencyPower
      
     threshold:Int
      
     Variation
     points
     HighSpeed  &    threshold>100    
      EmergencyPower  
     HighSpeed
      
     :ObjectExistence   :SlotValueAssignment  
     :ObjectExistence   :ObjectExistence  
     Based  Model    
     Adapted  from  the  CVL  tutorial  at  SPLC’12  by  Oystein  Haugen,  Andrezj  Wasowski,  Krzysztof  
     Czarnecki    
     

     View Slide

161. Variability  RealizaCon  Layer  
     VariaCon  points  in  CVL  
     •  VariaWon  Points  refer  to  Base  objects  
     •  VariaWon  Points  define  the  base  model  
     modificaWons  precisely  
     •  There  are  different  kinds  of  VariaWon  Points  
     – Existence  (object  or  link)  
     – Value  assignment  
     – SubsWtuWon  
     – Opaque  variaWon  point  
     – Configurable  Unit  
     Adapted  from  the  CVL  tutorial  at  SPLC’12  by  Oystein  Haugen,  Andrezj  Wasowski,  Krzysztof  
     Czarnecki    
     

     View Slide

162. Derivation of Traffic Lights
     Models
     Joao  Bosco  Ferreira  
     Filho  (PhD  student)  
     

     View Slide

163. Traffic Lights
     

     View Slide

164. . Traffic Lights' behaviour can be modelled using Finite
     State Machines
     Traffic Lights FSM
     

     View Slide

165. Traffic Lights FSM
     OBJECTIVE:
     Produce the finite state machine associated with
     each traffic light configuration
     . Simplification:
     - Green Light
     - Red Light
     - Yellow Light
     

     View Slide

166. Base model
     . Define the DSL:
     1. Create an Ecore modelling project
     2. Define the metamodel
     3. Generate the model, the edit and the editor code
     4. Export them as plugins
     

     View Slide

167. DSL metamodel
     

     View Slide

168. Base model
     . Create the base model:
     1. Create a Modelling project
     2. Create a new model in the DSL
     

     View Slide

169. Base model
     . Create the base model:
     1. Create a Modelling project
     2. Create a new model in the DSL
     

     View Slide

170. CVL model
     . Create the CVL model:
     1. Create a new CVL model in the modelling project.
     Select VPackage as the Model object
     2. Right click on the project, select Viewpoints selection.
     Check the three of them
     3. Define the VAM, Resolution model and VRM
     

     View Slide

171. VAM
     

     View Slide

172. Resolution model
     

     View Slide

173. Resolution model
     

     View Slide

174. VRM
     

     View Slide

175. VRM
     

     View Slide

176. Product derivation
     

     View Slide

177. Derived FSM
     

     View Slide

178. Visualisation of products in a
     web configurator
     Marianela Ciolfi Felice
     (MSc student)  
     

     View Slide

179. View Slide

180. Marks  &  Spencer  web  configurator  
     

     View Slide

181. §  High visual quality
     §  Coherence and stability
     §  Interactiveness
     §  Performance
     §  Automatic and comprehensive
     update method
     Marianela Ciolfi Felice and Joao Bosco Ferreira Filho and Mathieu Acher and Arnaud
     Blouin and Olivier Barais « Interactive Visualisation of Products in Online Configurators:
     A Case Study for Variability Modelling Technologies » MAPLESCALE’13 (to appear)
     

     View Slide

182. Anticipating all possible
     combinations
     §  10 configuration options
     §  10 possible values for each of
     them
     10.000.000.000 combinations!
     Composing the
     visualisation
     

     View Slide

183. PRODUCT CONFIGURATION VISUAL REPRESENTATION
     Models  
     HTML  
     jpg,  png,  ...,  
     files  
     SVG  files  
     Javascript  
     3D  
     models  
     Feature  
     models  
     

     View Slide

184. Configurations
     Derivation
     Process
     Visual
     representation
     of a product
     Feature
     Model
     How to
     realize the
     variability
     Visual
     elements
     

     View Slide

185. . Simplification:
     - Fabric
     - Collar
     - Pocket (optional)
     - Handkerchief (optional)
        
     Shirts web configurator
     

     View Slide

186. Shirts web configurator
     OBJECTIVE:
     Produce the visual representation associated with
     each shirt configuration
     . Simplification:
     - Fabric
     - Collar
     - Pocket (optional)
     - Handkerchief (optional)
        
     

     View Slide

187. Feature model
     - Implicit boolean attribute existence
     - No constraints
     

     View Slide

188. Base model
     . Define the DSL:
     1. Create an Ecore modelling project
     2. Define the metamodel
     3. Generate the model, the edit and the editor code
     4. Export them as a plugin
     

     View Slide

189. DSL metamodel
     

     View Slide

190. Base model
     . Create the base model:
     1. Create a Modelling project
     2. Create a new model in the DSL
     

     View Slide

191. Base model
     . Create the base model:
     1. Create a Modelling project
     2. Create a new model in the DSL
     

     View Slide

192. CVL model
     . Create the CVL model:
     1. Create a new CVL model in the modelling project. Select VPackage as the Model
     object
     2. Right click on the project. Select Viewpoints selection. Check the three of them
     3. Define the VAM, Resolution model and VRM
     

     View Slide

193. VAM
     

     View Slide

194. VAM
     

     View Slide

195. VAM
     Suggestion:
     Set the choices' default resolution
     to:
     - True for mandatory features
     - False for optional features
     

     View Slide

196. Resolution model
     

     View Slide

197. Resolution model
     

     View Slide

198. VRM
     

     View Slide

199. VRM
     

     View Slide

200. Product derivation
     

     View Slide

201. Product derivation
     

     View Slide

202. Summary:
      Variability  Model  Management  
     202  
     202  
     202  
     

     View Slide

203. [MOTIVATION/PROBLEM]  Why  modeling  and  managing  Variability  
     does  and  will  maber  (30’)  
     [SOLUTION  FOR  MANAGING  FEATURE  MODELS]  Managing  Variability  
     Models  with  FAMILIAR  (1h45’)  
      
      
     [SOLUTION  FOR  MODEL-­‐BASED  DERIVATION  OF  PRODUCT]  Model-­‐based  
     variability  engineering:  examples,  support  and  open  issues  
     (45’)  
     203  
     Key  Insights  
     

     View Slide

204. (ongoing)  
     Comprehensive  model-­‐based  
     product  line  support  
      
     Reverse  engineering  
     Automated  Analysis  
     Languages,  API/DSLs  
     EvaluaCon  (European  projects,  long-­‐term  collaboraCon  with  Thales,  open  source  
     systems)
      
       204  
     204  
     

     View Slide

205.  
      
      
      
      
        
      
      
      
     ?  
     205  
     

     View Slide