Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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.

FAMILIAR project

July 03, 2013
Tweet

More Decks by FAMILIAR project

Other Decks in 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. 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. 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. 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. 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  
    [email protected])  
    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. 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  [email protected]  
    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  
    [email protected]  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