Acher PhD thesis defense

of 62/62
Managing Multiple Feature Models: Foundations, Language and Applications PhD candidate: Mathieu Acher PhD supervisors: Philippe Lahire and Philippe Collet
  • date post

    15-Dec-2014
  • Category

    Technology

  • view

    389
  • download

    0

Embed Size (px)

description

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).

Transcript of Acher PhD thesis defense

  • 1. Managing Multiple Feature Models:Foundations, Language and Applications PhD candidate: Mathieu AcherPhD supervisors: Philippe Lahire and Philippe Collet

2. Software intensive systemsare declined in many variantsVARIABILITY MODELS2 3. VARIABILITY MODELSOPERATORS LANGUAGE Medical ImagingAPPLICATIONS Video surveillance FraSCAti3 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 ApplicationsMedical ImagingVideo surveillanceFraSCAti 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 Perspectives5 6. Assembly Line andMass Customization 6 7. a set of software- intensive systems that share a common, managed setof features satisfying the specific needs of a particular market segmentor mission and that are developed from a common set of core assets in aprescribed way [Clements et al., 2001]SoftwareProduct Lines 7 8. Software Product Line EngineeringFactoring out commonalitiesfor Reuse [Krueger et al., 1992] [Jacobson et al., 1997]Managing variabilitiesfor Software Mass Customization [Bass et al., 1998] [Krueger et al., 2001], [Pohl et al., 2005]8 9. Reuse-in-the-large worksbest in families of relatedsystems, and thus is domaindependent. [Glass, 2001]Domain engineeringDomain Analysis Domain Implementation(problem) (solution) elicitate requirements and scope the line variability modeling: determinecommonalities and variabilities usually inC++terms of featuresUMLmodel service Common assetsVariantsVariability ModelReusable Assets (e.g., models or source code) 9(Feature Model) 10. Domain engineering (development for reuse) central to the software product Common assetsVariants Feature Modelline 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 Configurationsproduct1 product2 productnApplication 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 Perspectives11 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 Modelsdescribe the common and variable features(characteristics) of a system under study Medical ImageModality AcquisitionFormat AnonymizedMRIPETDICOMNiftiT1 T2 T1 or T2 excludes Anonymized DICOM implies AnonymizedPET or Anonymized13 14. Feature Models Hierarchy: rooted tree Variability: mandatory, optional, Groups: exclusive or inclusive features Cross-tree constraints Medical ImageModality AcquisitionFormat AnonymizedMRIPETDICOMNiftiT1 T2 T1 or T2 excludes Anonymized DICOM implies AnonymizedPET or Anonymized14 15. Feature ModelsHierarchy + Variability = set of valid configurations Medical ImageModality AcquisitionFormat AnonymizedMRIPETDICOMNiftiT1 T2 T1 or T2 excludes Anonymized DICOM implies AnonymizedPET or Anonymized15 16. Feature ModelsHierarchy + Variability = set of valid configurations Medical Image Illegal configurationModality AcquisitionFormat AnonymizedMRIPETDICOMNiftiT1 T2 T1 or T2 excludes Anonymized see Or-group: DICOM implies AnonymizedPET or Anonymized at least one feature should be selected 16 17. Feature ModelsHierarchy + Variability = set of valid configurations Medical Image Illegal configurationModality AcquisitionFormat AnonymizedMRIPETDICOMNiftiT1 T2 T1 or T2 excludes Anonymizedsee constraint PET or Anonymized DICOM implies AnonymizedPET or Anonymized17 18. Feature Models Hierarchy + Variability = set of valid configurations Medical Image Satisfiability (NP-complete)Modality AcquisitionFormatAnonymized Configuration CheckingMRIPETDICOMNiftiT1 T2 T1 or T2 excludes Anonymized Dead features detection DICOM implies AnonymizedPET or AnonymizedAround 30 reasoning operations [Schobbens et al., 2007] [Benavides et al., 2010] 18 19. Propositional Feature Models Hierarchy + Variability = set of valid configurationsPropositional formula (^, v, ~, , =>)Boolean variables Medical Image set of valid assignmentsModality AcquisitionFormat Anonymized = Medical Image ^MRIPETDICOMNiftiFormat 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 Perspectives20 21. Feature models are becoming large and complex + 5000 features Constraint involving 50 featuresScalability issues in terms of - construction - evolution - reasoning 21 22. Multiple Feature ModelsSPL/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 .. constraintsconstraints 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) FAMILIAR22 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 Perspectives23 24. Case Study: Medical Imaging Services Scientists assemble a wide variety of medical imagingservices (algorithms) Processing chain to manipulate large medical data sets Workflow24 25. (1) Medical imaging services are highly variable input medical imageMedical Imageoutput medical imageMedical Image Modality AcquisitionFormatAnonymizedMRI CT SPEC PET DICOM Nifti AnalyzeModality Acquisition FormatAnd-Group Xor-Group T1 T2OptionalOr-Group MRICT SPECPET DICOM NiftiMandatory And-Group Xor-Group T1 T2Optional Or-GroupMandatoryMedicalImagingService RegistrationGridComputingNode Transformation MethodInteractiveOperating SystemProcessorFileSizeLimit Linear Non Grid Spatial Frequency NetworkProtocolAnd-Group Xor-Group Optional Or-GroupWindowsLinuxx32 x64Mandatory Rotation Scaling Affine HeaderEncoding And-GroupOptionalXor-GroupOr-GroupFormatCryptographicalgorithm methodsMandatoryXML HTTP And-Group Xor-Group grid deploymentOptional Or-GroupMandatory network protocol variability 25 26. (2) Managing the in the entire workflow Medical ImageModality AcquisitionMedical ImageFormatAnonymizedMRI PET DICOM Nifti Modality Acquisition T1 or T2 excludes Anonymized Format AnonymizedT1 T2 DICOM implies AnonymizedPET or Anonymized MRIPETDICOMNifti T1 T2 T1 or T2 excludes AnonymizedDICOM implies Anonymized PET or Anonymized Medical ImageModality AcquisitionFormatAnonymizedMRIPETDICOMNiftiT1 T2 T1 or T2 excludes AnonymizedMedical Image DICOM implies AnonymizedPET or Anonymized Modality Acquisition Format Anonymized MRIPETDICOMNifti T1 T2 T1 or T2 excludes AnonymizedDICOM implies Anonymized PET or Anonymized Medical ImageModality Acquisition Format Anonymized MRI PET DICOMNiftiT1 T2T1 or T2 excludes AnonymizedDICOM implies Anonymized PET or AnonymizedMedical Image Modality AcquisitionFormatAnonymized MRIPET DICOMNiftiT1T2T1 or T2 excludes Anonymized DICOM implies AnonymizedPET or Anonymized Medical ImageModality AcquisitionFormatAnonymizedMRIPETDICOMNiftiT1 T2T1 or T2 excludes AnonymizedDICOM implies Anonymized PET or Anonymized 26 27. 27 Suppliern Int2 Int3 Segm2 Reg3 Reg2. 01101010 01101010 0110101001101010 01101010. 10100111 10100111 1010011110100111 10100111 00101010 00101010 0010101000101010 00101010 00101010 00101010 0010101000101010. 00101010 101101 101101 101101101101 Supplier2 101101011010100110101001101010011010100110101010100111101001111010011110100111101001110010101000101010001010100010101000101010 Supplier10010101000101010001010100010101000101010101101101101101101101101101101Reg1 Int1Segm3Reg4Segm1(3) Services come from different suppliers 28. ManagingMultiple Feature Models Segm110110100101010001010101010011101101010 Reg4 101101 00101010 00101010 10100111 01101010Segm3 101101 00101010 00101010 10100111 0110101010110100101010001010101010011101101010Int110110100101010001010101010011101101010Reg1Supplier1 101101101101 101101101101101101Supplier200101010 . 0010101000101010 001010100010101000101010 0010101000101010 001010100010101010100111 1010011110100111 1010011110100111 0110101001101010 011010100110101001101010 . . Medical Image Reg2Reg3 Segm2Int3Int2Modality AcquisitionFormat AnonymizedMRIT1 T2 PETDICOMNiftiT1 or T2 excludes AnonymizedSuppliern DICOM implies AnonymizedMedical ImagePET or AnonymizedModality AcquisitionFormat AnonymizedMRIPETDICOMNiftiT1 T2 T1 or T2 excludes Anonymized DICOM implies AnonymizedPET or AnonymizedMedical Image Medical Image Modality Acquisition Format AnonymizedModality Acquisition MRIFormat AnonymizedPETDICOMNifti T1 T2 T1 or T2 excludes AnonymizedDICOM implies Anonymized PET or AnonymizedMRIPETDICOMNiftiT1 T2 T1 or T2 excludes Anonymized DICOM implies AnonymizedPET or AnonymizedMedical Image Modality AcquisitionFormat Anonymized MRIPET DICOMNifti Medical Image T1 T2T1 or T2 excludes Anonymized DICOM implies Anonymized Medical ImagePET or AnonymizedModality AcquisitionFormat Anonymized Modality Acquisition Format AnonymizedMRIPETDICOMNifti MRIPETDICOMNiftiT1 T2 T1 or T2 excludes Anonymized DICOM implies AnonymizedPET or AnonymizedT1T1 or T2 excludes AnonymizedT2DICOM implies Anonymized PET or Anonymized28 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 Perspectives29 30. Approach forManaging Multiple Feature Modelsconstraintsconstraints.. .. 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 Perspectives31 32. Different forms of compositionFMMIsupport insert Medical Imageaggregate merge aggregateFMalgo FormatMI Algorithm ModalityAcquisition FMalgo MethodInteractiveFMMIsupport.PET implies FMalgo.PAM MI AlgorithmSPECPET Name insert CTFMMIsupport.CT or FMMIsupport.SPEC implies FMalgo.BAM ModelinsertAtlas Method GridNon Interactive FMMIsupportPAM BAMModelCFL EMS Medical ImageMedical ImageMedical Image DICOMNiftiAnalyzeAtlas Non Grid Medical Image Input feature modelsPAMModality Acquisition Modality Acquisition Format AnonymizedModality Acquisition Format AnonymizedFormat AnonymizedMRIPETDICOMNifti MRIBAMPETDICOMNiftiMRIPETDICOMNiftiT1 T2 T1 or T2 excludes Anonymized DICOM implies Anonymized T1 T2 T1 or T2 excludes AnonymizedPET or AnonymizedT1 or T2 excludes AnonymizedDICOM implies AnonymizedT1 T2PET or AnonymizedPET implies DICOM or Analyze DICOM implies AnonymizedPET or AnonymizedCFLEMSAnalyze excludes (CT and SPEC)ModalityAcquisitionFormat merge CTSPECPET NameMedical ImageModality Acquisition FormatAnonymized DICOM Nifti AnalyzeMRI PET DICOMNifti Composed feature model FMMRI PET implies DICOM or AnalyzeT1 T2 T1 or T2 excludes Anonymized DICOM implies AnonymizedPET or AnonymizedFMmdata Analyze excludes (CT and SPEC)FMalgo1 FMalgo2 MRIMI Algorithm MI AlgorithmMetaDataMethodMethodInteractiveSemantics: we characterize composed feature model in terms of T1T2 AnonymizedModel Atlas Atlas Non Grid input sets of configurations CFL EMSPAM BAM CFLEMS input hierarchies32 33. 33 ???I want a segmentation service. Suppliern Int2 Int3 Segm2 Reg3 Reg2. 01101010 01101010 0110101001101010 01101010. 10100111 10100111 1010011110100111 10100111 00101010 00101010 0010101000101010 00101010 00101010 00101010 0010101000101010. 00101010 101101 101101 101101101101 Supplier2 101101011010100110101001101010011010100110101010100111101001111010011110100111101001110010101000101010001010100010101000101010 Supplier10010101000101010001010100010101000101010101101101101101101101101101101Reg1 Int1Segm3Reg4Segm1Merging Feature Models 34. Merge Intersection: Available Suppliers Suppliers? Configurations? A scientist has some requirements 34 35. Merge Union: Availability CheckingYes! Can suppliers provide all services?comparisonsee [Thuem et al., 2009] 35 36. How to implement merge operators?Medical ImageMedical Image MedicaI Image AnonymizedMRIHeader Anonymized MRIDICOM AnonymizedMRI DICOMT1 T2T1 T2 T1 T21 2 3Medical Image123+ Anonymized MRIHeader DICOMT1T2 merged propositional formulamerged hierarchyMedical ImageSet mandatory featuresDetect Xor and Or-groups Anonymized MRI Header DICOMCompute implies/excludes Header excludes DICOMconstraintsT1T2 Header implies Anonymized Anonymized v Header v ~DICOM v ~T1 v ~T2 Anonymized v Header v DICOM v ~T1 v ~T236[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] 37see Chapter 5, [Acher et al., SLE09] or [Acher et al., ECMFA10] 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 Perspectives38 39. A first try fm0 RA PA1 A2 P1P2P3 P1 => P2 A3A4 A5A6 A3 => P1 P2 => A5 fmExtraction2 fmExtraction1 A A A3 => A5A1A1 A2 A2A4 => A6 A3A4 A4A5 A5 A6A6Problem: You can select A3 without A5We want a more generic, semantics-aware technique39 40. Slicing Operatorslicing criterion: subset of featuresfm1W PT U OptionalXor-Group Mandatory Or-GroupRS V AconstraintsE implies D B C DR implies ED excludes FS implies (F and not E) E Fconstraints TE implies DD implies Eslice: a new feature model SE D40 41. How to implement the slice operator? fm1W 1 PT U OptionalXor-Group Mandatory Or-GroupRS V AconstraintsE implies D B C DR implies ED excludes F existentialS implies (F and not E) E F quantification of featuresT +not included in the slicings1 criterion SE DconstraintsTE implies DD implies E S ED 41 42. Corrective Capabilities of theSlicing Operatorslicing criterion: subset of featuresfm1W PT U OptionalXor-Group Mandatory Or-GroupRS V AconstraintsE implies D B C DR implies ED excludes FS implies (F and not E) E F Pslice: a new feature model RS42 43. Updating feature model viewsFMgridGridDeploymentFMalgoLibrary Required GridComputingNode MI AlgorithmMatlabMethodInteractive OSProcessor FileSizeLimitAuthentification Model FMalgo_UPDATED Atlas Linear Non GridMI AlgorithmWindows LinuxBitsGPUPAM BAM CFLEMS Affine Kerberos Password SSLAuthMethod Interactive x32x64 Rotation ScalingUbuntu Sc. Linux Sc. Linux excludes MatLab EMS implies Affine or Scaling:grid :algModelMedical Imaging Registration ServicePAMFMproto:proto :outNetworkProtocolFMMIsupport Medical ImageTransferProtocolNetworkSecurityHeaderEncoding ModalityAcquisitionFormat HTTPS HTTPCrypto PGP SSLMRI CT SPEC PETName MetaDataAsymetricSymetricAnonymized DESTripleDES KDC T1 T2DICOMNifti Analyze FMMIsupport_UPDATED HeaderEncoding implies HTTPS MetaData implies DICOM or Analyze Medical ImageconstraintsAnalyze excludes (CT and SPEC and T1) FMgrid..Kerberos implies FMproto.KDC ModalityAcquisitionFormat FMgrid..SSLAuth FMproto.SSL MRICTPETNameMetaData FMMIsupport.MRI implies FMalgo.PAMAnonymized FMMIsupport.CT or FMMIsupport.SPEC implies FMalgo.BAM T2 Nifti Analyze FMMIsupport.Anonymized implies FMproto.HeaderEncodingMetaData implies AnalyzeAnalyze 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 PerspectivesFMgridGridDeploymentFMalgoLibrary Required GridComputingNode MI AlgorithmMatlabMethodInteractive OSProcessor FileSizeLimitAuthentification Model constraints Atlas Linear Non GridWindows LinuxBitsGPUPAM BAM FMgrid..Kerberos implies FMproto.KDC CFLEMS Affine Kerberos Password SSLAuthFMgrid..SSLAuth FMproto.SSL x32x64 Rotation ScalingUbuntu Sc. Linux Sc. Linux excludes MatLab EMS implies Affine or ScalingFMMIsupport.MRI implies FMalgo.PAM:grid :algMedical Imaging FMMIsupport.CT or FMMIsupport.SPEC implies FMalgo.BAM Registration ServiceFMMIsupport.Anonymized implies FMproto.HeaderEncodingFMproto:proto :outNetworkProtocolFMMIsupportFMalgo.Interactive implies FMproto.HeaderEncoding Medical Image HeaderFMgrid.GPU excludes FMalgo.InteractiveTransferProtocolNetworkSecurityEncoding Crypto ModalityAcquisitionFormatFMalgo.Interactive implies FMgrid..Linux HTTPS HTTP PGP SSLAsymetricSymetric MRI CT SPEC PETName MetaDataFMMIsupport.DICOM implies FMproto.Rotation and FMproto.PAMAnonymized DESTripleDES KDC T1 T2DICOMNifti Analyze HeaderEncoding implies HTTPS MetaData implies DICOM or AnalyzeSecurity features Analyze excludes (CT and SPEC and T1)The same feature models and constraints Aggregate + Slice44 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 45see Chapter 7 or [Acher et al., ASE11] 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 Perspectives46 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,Kstner et al., 2009] Domain-specific language FAMILIARFeAture Model scrIpt Language for manIpulation and Automatic Reasoningsee chapters 8 and 9, [Acher et al., SAC11], [Acher et al., VaMoS11] or [Acher et al., ASE11]47 48. And-Group Xor-Group GraphicCardOptional Or-GroupMandatoryOutputsDirectXTV outputVIVODVI HDMI VGAV10 V10.1 v11 // foo.fmlconstraints S-Video CompositeVGA excludes TV outputHDMI 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, TVconstraints.. fm6 = slice fm5 including fm5.TV.* And-Group Xor-Group export fm6 Optional Or-Group Mandatoryconstraints.. constraints ..domain-specific languageFAMILIAR 49. FAMILIAR featuresfm1 = FM(foo.tvl)fm2 = FM (foo.m)serialize fm4 into SPLOTfm3 = FM (foo.xmi)fm4 = FM (A : B .) Interoperability serialize fm1 into featureide configurationcounting configs cores deadsselect isValidcompareReasoningfalseOptionalsdeselectasFMmergeaggregate diff insert intersection sunion(De)Composition extract map unmapslicing renameFeature setOptionalEditingremoveFeaturesetMandatory accessors setAlternativescopy setOr modular mechanisms fm1.* fm1.Biterator/conditionalassertion Language Facilities restricted set of types 49 50. 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 Perspectives50 51. With the MODALIS team SuppliernInt2 Int3 Segm2 Reg3 Reg2 .01101010 01101010 011010100110101001101010 .10100111 10100111 10100111101001111010011100101010 00101010 00101010001010100010101000101010 00101010 0010101000101010 .00101010101101 101101 101101101101Supplier2 101101 0110101001101010011010100110101001101010 1010011110100111101001111010011110100111 0010101000101010001010100010101000101010Supplier1 0010101000101010001010100010101000101010 101101101101101101101101101101 Reg1 Int1Segm3Reg4Segm1 The case of medical imaging workflowsto Assemble Coherent WorkflowsComposing Multiple Variability Artifacts 52. Contributions Multi-step process MRI T1 Modality AcquisitionT2PETMedical Image DICOM FormatNiftiAnonymized T1 or T2 excludes AnonymizedDICOM implies Anonymized PET or Anonymized MRI T1 Modality AcquisitionT2 PET Medical ImageDICOMFormat Nifti AnonymizedT1 or T2 excludes Anonymized DICOM implies AnonymizedPET or Anonymized Specification of variability concerns Medical ImageModality AcquisitionFormatAnonymizedMRIPETDICOMNiftiT1 T2 T1 or T2 excludes Anonymized DICOM implies AnonymizedPET or AnonymizedMedical Image Modality AcquisitionFormatAnonymized MRI PETDICOMNiftiT1T2 T1 or T2 excludes AnonymizedDICOM implies Anonymized PET or Anonymized FAMILIAR as an embedded language Catalog of reusable servicesSegm110110100101010001010101010011101101010 101101 00101010 00101010 10100111 01101010Reg4 101101 00101010 00101010 10100111 01101010 Segm310110100101010001010101010011101101010Int110110100101010001010101010011101101010Reg1Supplier1 Building and querying a catalog of feature models101101 00101010 00101010 10100111 011010101011010010101000101010101001110110101010110100101010001010101010011101101010 101101 00101010 00101010 10100111 01101010 101101 00101010 00101010 10100111 01101010Supplier2 . . . Automated reasoning techniquesReg2 Reg3 Segm2 Int3Int2 Suppliern Propagation choices, updating feature model views FMgrid FAMILIAR as a target languageGridDeploymentFMalgoLibrary Required GridComputingNode MI AlgorithmMatlab Method Interactive OS Processor FileSizeLimitAuthentificationModelAtlasLinear Non GridWindowsLinux Bits GPUPAM BAM CFLEMSAffine Kerberos Password SSLAuthx32 x64 RotationScalingUbuntuSc. Linux Sc. Linux excludes MatLab EMS implies Affine or Scaling:grid:algMedical Imaging Registration ServiceFMproto :proto :out NetworkProtocolFMMIsupport First experimental resultsMedical ImageTransferProtocolNetworkSecurityHeaderEncoding ModalityAcquisition Format HTTPS HTTPCrypto PGP SSL MRI CTSPEC PETName MetaData AsymetricSymetricAnonymizedDES TripleDESKDC T1T2 DICOM Nifti Analyze HeaderEncoding implies HTTPS MetaData implies DICOM or Analyze Analyze excludes (CT and SPEC and T1) 3 real scientific workflows Better user assistance and degree of automation52see Chapter 9, [Acher et al., SC10] or [Acher et al., Software Quality Journal, 2011] 53. Modeling Variability From Requirements to Runtime The case of video surveillance processing chainslarge number of software configurationsAdaptive systems (see DiVA project)for a large number of requirements Collaboration with Sabine Moisan and Jean-Paul Rigault (INRIA) 54. Contributions Separation of Concerns Software variability is distinguished from requirements variability A systematic approach to specify and reason aboutvariability of adaptive systems Variability requirements are step-wised specified at design time Some variability choices are kept for runtime adaptation (e.g., Day/Night) Reduction of software configurations to be considered at runtime Reasoning operations Consistency checking Reachability property for all valid requirements (e.g., contexts), there exists at least one valid software configuration Specialization checking Choices Propagation Language support aggregate + slice + compare + editing facilities Reuse of feature models and analysis procedures in 6 scenarios54see Chapter 10 or [Acher et al., ICECCS11] 55. Reverse Engineering Architectural Feature Models Case Study: FraSCAti ArchitectureFM1 FraSCAtiSCAParserAssembly Factory Component FactoryMetamodel BindingJava CompilerMMFrascati MMTuscany httprestJDK6 JDT constraintsAlternative-Optional Grouprest requires MMFrascatiOr-GroupMandatoryhttp requires MMTuscanyCollaboration with Anthony Cleve (University of Namur / PRECISE, Belgium),Philippe Merle and Laurence Duchien (University of Lille / INRIA) 56. Contributions Automated Procedure Extracting and combining variability sources FAMILIAR as a target language Integration of software architect knowledge Reconciliation process Interactive process with FAMILIAR Extensive use of operators aggregate, slice, merge, compare, editing facilities Reverse engineering process impossible without the operators Lessons Learned Extraction procedure yields promising results Essential role of software architect To validate the extracted feature model To integrate knowledge56see Chapter 11 or [Acher et al., ECSA11] 57. 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 Perspectives57 58. Contributions Composing, decomposing and reasoningabout multiple feature models Set of operators with formal semantics, automated implementation Brings new capabilities for feature model users FAMILIAR Domain-Specific Language for large scale feature model management Applications Medical Imaging (1) Catalog of Services (2) Managing Variability in Scientific Workflows Video Surveillance Modeling Variability from Requirements to Runtime Reverse Engineering of Feature Models Architectural variability of FraSCAti58 59. Ongoing Work Consolidating and evolving tools Evaluation of the language on a larger scale Applicability to other domains Scalability of the operators Are new operators needed? Language from a user perspective learnability, expressiveness, productivity Integration of the language into a comprehensivesoftware development chain e.g., in an adaptive architecture for video surveillancesystems, [Moisan et al., ICVS11] 59 60. Domain engineering (development for reuse) Common assetsVariants Feature ModelReusable Assets(e.g., models or source code)Feature Configurations product1 product2productnApplication engineering (development with reuse) 60 61. Compositional Software Product Lines [Bosch et al., 2010]Textual Requirements UMLUse Case DiagramClass DiagramSequence DiagramOntologySource Code Feature modules Preprocessor Aspect Model-driven Engineering[Czarnecki, France, Jzquel]61 62. OPERATORS LANGUAGE Medical Imaging Video surveillanceAPPLICATIONS FraSCAti62