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