Acher PhD thesis defense

  • Published on
    15-Dec-2014

  • View
    388

  • 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

  • 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 Engineeri...