際際滷

際際滷Share a Scribd company logo

Featured Model Types

Gilles Perrouin
Gilles Perrouin

際際滷s of my talk at the Models In Software Engineering Workshop (MISE) co-located with the International Conference on Software Engineering (ICSE), Austin Texas, May 16, 2016

1 of 49
Download to read offline
Featured Model Types Gilles Perrouin, Moussa Amrani, Mathieu Acher, Beno樽t Combemale, Axel Legay, Pierre-Yves Schobbens Towards Systematic Reuse in Modelling Language Engineering MISE@ICSE, Austin May 16, 2016
www.unamur.be Reuse Dimensions [1] 2 Granularity Scope Specificity [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):537572, May 2015.
www.unamur.be Reuse Dimensions [1] 2 Granularity Scope Specificity [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):537572, May 2015.
www.unamur.be Reuse Dimensions [1] 2 Granularity Scope Specificity [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):537572, May 2015.
www.unamur.be Reuse Dimensions [1] 2 Granularity Scope Specificity LARGE: (trans parts, or in full) SMALL: (functions, rules, etc.) [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):537572, May 2015.
www.unamur.be CONCRETE: Bound to a specific metamodel / trans language GENERIC: Independent of metamodel / trans language Reuse Dimensions [1] 2 Granularity Scope Specificity LARGE: (trans parts, or in full) SMALL: (functions, rules, etc.) [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):537572, May 2015.
www.unamur.be CONCRETE: Bound to a specific metamodel / trans language GENERIC: Independent of metamodel / trans language Reuse Dimensions [1] 2 Granularity Scope Specificity LARGE: (trans parts, or in full) SMALL: (functions, rules, etc.) Inter: Reused across many transformations INTRA: Reuse inside the same transformation [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2):537572, May 2015.
www.unamur.be Model Reuse Strategies By adapting the transformation to be reused By adapting the source metamodel 3 [1] Salay, Rick and Famelis, Michalis and Rubin, Julia and Di Sandro, Alessio and Chechik, Marsha. Lifting Model Transformations To Product Lines. ICSE, 2014. [2] de Lara, Juan and Guerra, Esther and Cuadrado, Jesus Sanchez.A-posteriori typing for Model-Driven Engineering. MoDELS 2015. [3] Tisi, Massimo and Jouault, Fr辿d辿ric and Fraternali, Piero and Ceri, Stefano and B辿zivin, Jean. On The Use of Higher-Order Transformations. MDA-FA, 2009. [4] Guy, Cl辿ment and Combemale, Beno樽t and Derrien, Steven and Steel, James and J辿z辿quel, Jean-Marc. On Model Subtyping. ECMFA, 2012. [5] Moha, Naouel and Mah辿, Vincent and Barais, Olivier and J辿z辿quel, Jean-Marc. Generic Model Refactorings. MoDELS 2009. [6] Sen, Sagar and Moha, Naouel and Mah辿, Vincent and Barais, Olivier and Baudry, Beno樽t and J辿z辿quel, Jean-Marc. Reusable model transformations. SoSyM, 11(1), 2010.
www.unamur.be Issues [1] 4 [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2): 537572, May 2015.
www.unamur.be Issues [1] I1 Insufficient abstraction from metamodel(s) to support metamodel-independent reuse 4 [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2): 537572, May 2015.
www.unamur.be Issues [1] I1 Insufficient abstraction from metamodel(s) to support metamodel-independent reuse By generalization: decouple transformation logic from type info By simplification: expose interface; hide realisation 4 [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2): 537572, May 2015.
www.unamur.be Issues [1] I1 Insufficient abstraction from metamodel(s) to support metamodel-independent reuse By generalization: decouple transformation logic from type info By simplification: expose interface; hide realisation I2 Lack of repositories for simplifying artifacts selection, at coarse- (e.g., full transfos) and fine-grained (e.g., functions) levels 4 [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2): 537572, May 2015.
www.unamur.be Issues [1] I1 Insufficient abstraction from metamodel(s) to support metamodel-independent reuse By generalization: decouple transformation logic from type info By simplification: expose interface; hide realisation I2 Lack of repositories for simplifying artifacts selection, at coarse- (e.g., full transfos) and fine-grained (e.g., functions) levels I3 Lack of meta-information for selecting appropriate reusable elements without knowing the transformations internal 4 [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2): 537572, May 2015.
www.unamur.be Issues [1] I1 Insufficient abstraction from metamodel(s) to support metamodel-independent reuse By generalization: decouple transformation logic from type info By simplification: expose interface; hide realisation I2 Lack of repositories for simplifying artifacts selection, at coarse- (e.g., full transfos) and fine-grained (e.g., functions) levels I3 Lack of meta-information for selecting appropriate reusable elements without knowing the transformations internal Provide documentation, pre-conditions, test models, formal requirements, etc 4 [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2): 537572, May 2015.
www.unamur.be Issues [1] I1 Insufficient abstraction from metamodel(s) to support metamodel-independent reuse By generalization: decouple transformation logic from type info By simplification: expose interface; hide realisation I2 Lack of repositories for simplifying artifacts selection, at coarse- (e.g., full transfos) and fine-grained (e.g., functions) levels I3 Lack of meta-information for selecting appropriate reusable elements without knowing the transformations internal Provide documentation, pre-conditions, test models, formal requirements, etc 4 [1] Kusel et al. Reuse in Model-To-Model Transformation Languages: Are We There Yet? SoSyM, 14(2): 537572, May 2015. Systematic reuse is not there yet
5
5 Systematising model reuse by adopting a product line approach
www.unamur.be Variations over an FSM 6 FSM State Transition Graph Vertex Edge FSM State Transition Init Final Normal current FSM State Transition time : real FSM State Transition
www.unamur.be Variations over an FSM 6 FSM State Transition Graph Vertex Edge FSM State Transition Init Final Normal current FSM State Transition time : real Applicable transformations: minimize() : FSM Applicable transformations: accept() : boolean Applicable transformations: wcet() : real FSM State Transition
www.unamur.be Variations over an FSM 6 FSM State Transition Graph Vertex Edge FSM State Transition Init Final Normal current FSM State Transition time : real Applicable transformations: minimize() : FSM Applicable transformations: accept() : boolean Applicable transformations: wcet() : real FSM State Transition Model Types capture the FSM variants, but what captures the Model Type Variants ?
www.unamur.be FMT: Whats in a name? Intent: Do not reinvent the wheel ! Reuse existing techniques as much as possible! Manage explicitly your language assets Operate with multi-granularity (both coarse-/fine-grained); Create repositories of specialised domain assets Configure your language ! 7
www.unamur.be 8 FSM Transition Init Final Normal current State time : real nested r h x t requires r / minimise() : FSM r h / flatten() : HFSM r t x / wcet() : real r x / accept() : Boolean FSM_FMT
www.unamur.be Domain Engineering Activities
www.unamur.be Building FMTs 10
www.unamur.be Building FMTs Purpose Define FMT construction approaches: Big Bang: Design FMTs explicitly w.r.t SPL paradigm Incremental: Start from a MT and incrementally add features and MM elements 10
www.unamur.be Building FMTs Purpose Define FMT construction approaches: Big Bang: Design FMTs explicitly w.r.t SPL paradigm Incremental: Start from a MT and incrementally add features and MM elements 10
www.unamur.be Building FMTs Purpose Define FMT construction approaches: Big Bang: Design FMTs explicitly w.r.t SPL paradigm Incremental: Start from a MT and incrementally add features and MM elements Challenges: providing construction primitives that support merging similar elements and features, correct by construction FMTs, evolution 10
www.unamur.be Validate FMTs 11
www.unamur.be Validate FMTs Purpose 11
www.unamur.be Validate FMTs Purpose Dealing with FMTs inconsistencies Structural: conflicting Names, references/ multiplicities mismatches => Can be addressed with variability-aware type checking Semantic: unintended interactions amongst transformations, transformations not meant to work on hierarchies, Can be addressed via SPL testing or verification 11
www.unamur.be Validate FMTs Purpose Dealing with FMTs inconsistencies Structural: conflicting Names, references/ multiplicities mismatches => Can be addressed with variability-aware type checking Semantic: unintended interactions amongst transformations, transformations not meant to work on hierarchies, Can be addressed via SPL testing or verification Challenges: Scalability of analyses, verifiability of transformations 11
www.unamur.be Application Engineering
www.unamur.be Configure and Derive an MT Product 13
www.unamur.be Configure and Derive an MT Product Purpose Configure your DSML the same way you configure your car Configurator partially generated from the feature model Product derivation techniques (e.g. pruning) to build desired MT automatically 13
www.unamur.be Configure and Derive an MT Product Purpose Configure your DSML the same way you configure your car Configurator partially generated from the feature model Product derivation techniques (e.g. pruning) to build desired MT automatically Challenges Partial configuration, user guidance on the relevance of elements (documentation issues) 13
www.unamur.be Validate MTs 14
www.unamur.be Validate MTs Purpose 14
www.unamur.be Validate MTs Purpose Perform QA activities that are too expensive at the domain engineering level (e.g. integration tests) 14
www.unamur.be Validate MTs Purpose Perform QA activities that are too expensive at the domain engineering level (e.g. integration tests) 14
www.unamur.be Validate MTs Purpose Perform QA activities that are too expensive at the domain engineering level (e.g. integration tests) Challenges Reusing validation artifacts from domain engineering, validating them (e.g. Mutation Analysis) 14
www.unamur.be Matching and Customising MTS 15
www.unamur.be Matching and Customising MTS Purpose 15
www.unamur.be Matching and Customising MTS Purpose Relating your MT with existing metamodels 15
www.unamur.be Matching and Customising MTS Purpose Relating your MT with existing metamodels Needed if your MT is not a DSML in itself but part of it 15
www.unamur.be Matching and Customising MTS Purpose Relating your MT with existing metamodels Needed if your MT is not a DSML in itself but part of it For fully derived MTs, existing techniques apply 15
www.unamur.be Matching and Customising MTS Purpose Relating your MT with existing metamodels Needed if your MT is not a DSML in itself but part of it For fully derived MTs, existing techniques apply 15
www.unamur.be Matching and Customising MTS Purpose Relating your MT with existing metamodels Needed if your MT is not a DSML in itself but part of it For fully derived MTs, existing techniques apply Challenges Dealing with partial MTs => variability-aware matching 15
www.unamur.be Conclusion We proposed a vision leveraging Model Types and Feature Modelling to support product-line engineering of modelling languages FMTs = support to manage reusable MM assets Wishlist of high-level operations to work with FMTs 16
www.unamur.be Future Work 17

More Related Content

Featured Model Types